MuleSoft Catalyst — Agree on Funding Model
Now, while the MuleSoft Catalyst talks about the funding of the C4E and puts forward three possible models I would guess that in most organisations it will be a much more complicated picture. As usual some fundamental questions will need to be addressed regarding what the funding will cover. Let’s think about some of the options so that you have some food for thought as I explore the rest of the suggested funding models put forward as part of the MuleSoft Catalyst C4E Playbook.
I suppose the first and most fundamental question must be what the funding is expected to cover? At first this may seem a straightforward question to answer — it’s the cost of the people required to operate the C4E. But is that all that the funding needs to cover? A successful C4E such as the one I have built with my colleagues has many more expenses and can become, if you are not careful and address the issues up front, a victim of its own success. It will become clear what I mean by this soon.
Of course, there will always be an operational cost to cover the people involved in the C4E and, depending on the structure in each organisation around the C4E, that is a given. How this cost is covered I will address later. But, an organisation may decide to recover all operational costs which may include the use of consultancy services, contractors, platform and IPaaS costs etc. The big one here, if the C4E and the API development process really takes off, is the continuing requirement for run time capacity in the form of MuleSoft vCores. These are not cheap, MuleSoft themselves will tell you this, so you need to plan what you may need and when you will need it. Get it wrong and you end up with vCores, which you have paid for, sitting doing nothing or on the other hand if you don’t buy enough you will restrict your capability to develop and / or deploy API’s into production it a timely and cost effective manner.
Now some organisations may say that funding is only to operate the C4E and that is fine. That is the approach that the playbook takes but I definitely think it is worth considering the holistic picture up front when talking about costs.
Getting back to the playbook then, let’s look at the suggested funding models and see what questions you need to think about.
The paybook suggests that in most organisations there will be well established processes for the procurement of software licences and delivery costs. From my experience delivery costs are generally those associated with projects undertaken by the organisation so this is probably a fair assumption and the same applies for software licences where most organisations, I would say, will have a software licencing team who will look to get the best deal possible for the organisation. Therefore, we now have to address the costs associated specifically with the C4E and examine the three models that exist within the playbook.
The three models are based on the organisation and constitution of the C4E in terms of human resources and are as follows:
Virtual Team: this is where the C4E is made up of people from other areas of the business and have only a part time contribution to the manning and running of the C4E. In this model, as people are primarily allocated to their ‘day jobs’ before the C4E came into life, and are not 100% allocated to the C4E, they are funded entirely from the role they originally occupied before the C4E work appeared. From my experience this makes the C4E the poor relation in the work environment and leads to a lack of prioritisation to the Integration and C4E capability. When demands on time increase the people paying for a resource get first call on that resource and, in this case, this would not be the C4E. This should certainly be recorded as a risk to the Integration capability of the organisation.
On the plus side I suppose, if there is a plus side, the virtual team would require no incremental funding but would rely on the good will of the primary resourcing manager of each virtual resource to allow the function to work well.
Dedicated Team: This is the complete opposite to the Virtual Team. In this case ‘new’ resources would be required from either external recruitment or the creation of new job roles to be permanently allocated to the C4E. There should be no doubt here that recruiting people with the required level of experience will not be of insignificant cost or, if internal people are to be trained, then training costs and time will need to be found. I would also suggest that the option of training internal resources will need to be supported by people who have the required MuleSoft experience. This may be MuleSoft professional services, contractors or third-party staff. Again there may be significant costs involved in this structure but, in return, you should get full commitment to the Integration capability.
Hybrid Team: A Hybrid C4E has a mixture of permanently assigned staff, one of which must be the C4E Lead, surrounded and supported by resources that are available on a ‘part-time’ basis to perform the work required by the C4E. Part time roles may include such functions as DevOps, CloudOps, Security etc. This can be the best of all worlds or the worst of all worlds. It requires the virtual part of the team, those operating on a part-time basis to be available and committed to the C4E when they are required. The funding of this type of team is also simpler in some ways but in some ways more complex as funding has to be provided by multiple routes leading to conflicts of commitment to the C4E.
Whichever team structure is finally adopted the C4E funding model does need to be in place right at the start of the project but the ongoing funding model, I would suggest, needs to be flexible in the mindset of the organisation. It is quite possible in my experience and from the conversation I have had with other colleagues, that the funding model may well change as the capability develops and the organisation gains a better understanding of what it has undertaken, its integration journey progression and the success that is achieved by the C4E. Remember, one of the prime outcomes of developing a MuleSoft capability is the ability to not only unleash data and make the API’s reusable but also to lay the foundation for innovation and unlock processes and capability that may not have been previously possible within the organisation.
Now, before I finish with a summary of the funding schemes within the paybook I want to address one of the issues that can come as a bit of a surprise if you suddenly find the C4E and API development capability taking off to be the success that everyone hopes to achieve. This is not mentioned at this stage in the playbook but I think it’s an issue worth raising here as it may affect the funding model either early on or as the capability progresses. The issue is the purchase of vCores which are required to support API’s in a Cloudhub development or production environment. Just to be clear the purchase of vCores depends on the type of MuleSoft implementation that you are using and I’m not going to address the technical details of these in this article but the costs can be significant and the organisation needs to decide at some point if they wish to recover these costs in some way or whether they will be centrally funded. To be honest this subject could be an article on its own and it’s certainly a subject that was discussed for a long time in our MuleSoft implementation work
Bearing this in mind let’s look at the funding models addressed in the playbook.
Common Source
Funding for all aspects of the C4E and the Integration capability are funded form a single source.
This model is probably the simplest model and the one that means that the C4E can focus on its strategy and delivery without having to manage the funding required to sustain a capability. The organisation sees the C4E as a valuable asset and wants to use it to delivery Integration capabilities across the business without the need to recover costs from individual projects using the capability. One outcome of this model may be the avoidance of the need to employ resources to manage the financial recovery aspects required by the following models.
Project-Based
Funding is supplied by each individual project using the capability paying for the resources they use.
If the C4E and supporting roles are not centrally funded then costs will need to be recovered from the C4E customers which will inevitably mean that the costs will need to be recovered from individual projects that are using the capability. This may mean that the early projects have the ability to shape the C4E as well as the way in which the platform is operated. When adopting this model the C4E will need to be very careful to ensure that assets are reusable and available to projects other than the funding project. Failure to do this will lead to the exact model that the API Lead Architecture is trying to avoid with the proliferation of point-to-point interfaces or the requirement to cross charge projects that use API’s that another project has funded. I would encourage anyone away from this model as it can get very complex very quickly and lead to many unforeseen charging and strategy issues.
Hybrid
Partly centrally funded and partly funded by the projects by charging for the resources that the project uses.
As you can guess by now the funding model is looking very similar in title to the resourcing model so the Hybrid funding model sees the C4E and possibly surrounding functions sourced centrally but with projects using the capability providing funding to offset the central cost dependent on the resources that they consume. This is where funding for vCores can be recovered through the development process and the ongoing running of the API in the production environment. One additional source of funding that may be considered, especially if the organisation is providing API usage to external customers, is to charge per API call. The capability to identify the number of API calls per customer is provided natively within the MuleSoft platform however additional processing and resources may be required to operate the invoicing of customers and the receipt of payments.
In conclusion there may be some other forms of cost recovery that the organisation may consider as part of the Project and Hybrid models such as charging projects for consultancy services at either the strategic or development level, charges for using CloudOps or DevOps tools and charges for ongoing support of API’s. Each organisation must make a choice to suite their requirements.
Although I will not go into detail here it is also important to consider costs that may be involved in the development and operation of API’s that are used in Mission Critical Systems and also cost involved in ensuring that the capability can support any Disaster Recovery requirements specified by customers (projects). Again this is a very complex subject and could be explored in much more depth given the gravity of the requirements.
One final thought here while we are talking about funding. It should be remembered that one of major benefits of the development and use of API’s is their reusability across the organisation. To this end charging individual projects for the development of System level API’s can be severely restricting to the progress of the C4E and the API capability as a whole. Why? Well, if a project see’s that multiple projects require access to the same data which they require, who is the project that is going to be the first to pay? In my experience none of them! They will all try and wait for each other. This is obviously not a tenable way forward so what do you do? Try and charge each project its share of the System API development and operation or pay for the development and operation from a central budget? Trying to cross charge each project can become a nightmare and I would suggest avoiding this at all costs. In my view the only way forward is to provide all System API’s from a central budget. This will promote reuse and provide central access to all key systems over time.
As a final thought on this are of the playbook I would encourage you to think long and hard about funding but, certainly at the top of my mind, was the idea that whatever was decided it need to be as simple as possible to both understand and implement. Don’t distract from the technical benefits and opportunities for innovation by introducing the need to operate a complex funding model.
