MuleSoft Catalyst — Centre for Enablement
The next episode — Build to Scale
As a summary for anyone that may not have read my previous article on the MuleSoft
Catalyst Methodology each of the six Playbooks that constitute the MuleSoft Catalyst Methodology are divided into four phases, Plan for Success, Establish the Foundation, Build to Scale and Measure Impact. This article focuses on the Build to Scale phase of the Centre 4 Enablement Playbook and will look at the activities that drive the consumption of API’s.
Drive Consumption
In the same vein as the phases there are four activities that are defined in the drive consumption phase of the Build to Scale element.
o Teams consume assets to deliver projects.
o Onboard additional project teams
o Identify and harvest additional reusable assets, standards and processes.
o Refine assets based on team feedback.
By this time in the acquisition and implementation journey your organisation, and the Centre for Enablement (C4E), should have established all of the initial foundational assets. Now, by assets I don’t just mean technical assets, yes there will be things like a common error handler, a common error logger and common audit logger but I also mean the fundamental strategic processes such as integration design standards, code standards and associated review processes the latter of which should be automated as much as possible. But this in itself is generally not good enough to prove the business benefit of the MuleSoft ecosystem. You need to ensure reuse!
The foundational assets need to prove their worth, and be subject to constant review, by being consumed by all of the organisations development teams when working on their API development processes. In order to make this a success two things have to happen.
The first is that the foundational assets need to be fit for purpose. Now while I say that they should be subject to constant review I am not saying that they should be subject to constant change, that would be counterproductive, but they do need to be managed to ensure they change with the organisation just as every other software asset.
The second thing that needs to happen, and I can’t emphasise how important this is, they need to be made available and publicised. If people don’t know they are there how can they be expected to use them? You do have a saving grace here if you have kept central control of API development in that the design and code review processes can ensure that common element have been used to build the API’s which come through the governance process.
Onboard additional Projects
In my previous article I have talked about onboarding the initial project teams to build the foundational API’s and assets. This part of the Build to Scale phase should now just be an extension of this work. If you built processes to onboard the initial teams then take that work, expand it to cover the assets and processes that were developed, and use it to onboard new teams. Don’t reinvent the wheel, just add a few more spokes to the current wheel. Some of the things that you need to do with new development teams are:
- Identify new development teams.
By this I mean understand who the new developers are, where they sit within the business organisation and what they are tasked to do. For some organisations this may mean a different development team in another branch of the organisation, it could mean an offshore or near shore team bought into complete a set task or it could mean a third-party organisation or consultancy bought into the business to deliver a major new system. Each of these circumstances may need to be addressed in a different way. Some of the different actions that need to take place may become clearer as we look at the following sections.
- Schedule their participation as follows:
a. New development teams need to be introduced to the C4E and the services, assets and procedures delivered and operated by the C4E. This will drive reuse of assets and ensure that standards and governance procedures are understood in order to save development time and increase business benefit.
b. If the new teams are internal to the organisation then training and certification in MuleSoft development may be required prior to the work starting on the new project. Ensure that this is planned into project timelines. If the new team is external to the organisation then they should hold MuleSoft certifications for the role they are performing. If the work is being delivered under a contract then the tender documents may need to include the requirement to supply appropriately qualified MuleSoft resources. All MuleSoft certifications can be checked with your MuleSoft customer success team.
c. Remember that, when building to scale and onboarding new teams, they may actually build assets that could become reusable assets that the C4E may wish to adopt. This is an important lesson to keep in mind and one which the C4E should be aware of at all times. Reuse does not just come from C4E delivered assets but the driving of reuse from all areas should be a key focus for the C4E. Assets identified this way should be taken under the supervision of the C4E and become part of the evangelisation message from the C4E.
- Update documentation, tune process
The Building to Scale activity should always be looking at updating documentation, both within Exchange and within the C4E wider documentation pool wherever this may reside. Remember in Exchange to make the API documentation customer focussed as well as technically accurate and relevant. Business users should be looking for API’s they can use and technical users will be looking for API’s they can reuse during their development processes.
Always look for ways to tune your processes. From personal experience I can definitely state that this needs to be done and will yield significant benefit in all respects. A C4E that stands still is a C4E that soon becomes irrelevant and of little benefit going forward.
Reusable Assets
Let’s explore reusable assets in a bit more detail. As I have said above the C4E, in order to remain relevant, needs to ensure that the existing C4E portfolio is up-to-date with reusable assets. The C4E needs to constantly review all assets but should periodically identify and publish any new development patterns, standards or any other best practices developed by the development teams within the organisation since the last C4E update. In this case, with the Build to Scale, this could be since the inception of the C4E. In addition, any new reusable APIs should be published to the C4E central repository. For any new assets the following details are some of the suggestions for information to be captured:
- Integration Process Name (business title)
- API technical name (if applicable)
- A plain language business description of what the asset is and its purpose
- Integration Type (e.g. Experience API, Process API, System API, Batch, Event Publisher, Event Listener, etc.)
- What value does this asset bring to the business?
- Candidate Resources (i.e. what would be possible resources provided by this API)
- Target Consumers — is this asset applicable to specific areas of the business or is it a foundational asset reusable across the whole business.
- What information is required to use the asset (if any)
This review additionally grants the C4E an occasion to pinpoint novel prospects for generating assets. For instance, this includes crafting System APIs for recently established systems or data repositories, as well as rejuvenating and enhancing assets that have undergone alterations.
Refine Assets
When refining assets the C4E must always look to actively seek feedback from the development teams and users that are consuming the API’s from MuleSoft Exchange and using the processes developed and deployed by the C4E. This is the best way to ensure that the C4E maintains a progressive entity providing benefit to the organisation. There are many different ways of asking for, receiving and processing feedback and in my view this should be done in association with the communications team within the organisation. Whichever way the feedback is captured there must be a process to use that feedback, validate it and improve where required. The following process is based on the suggestions in the MuleSoft Catalyst Playbook for this activity and should be overseen by the C4E.
Capture feedback from all applicable channels
1. The C4E should review suggestions from users, teams and customers and work with the resource providing the feedback to translate the suggestions into requirements of what is needed rather than a technical solution.
2. The C4E and owner of the asset, which may be the C4E itself, should review the requirement(s) and confirm if the requested enhancements are already available. If the enhancements are not available then determine if the enhancement request could be accepted or immediately rejected.
3. The C4E and the owner of the asset should work together to identify the impact of any changes and any dependencies on other assets.
4. At this stage it is possible that the changes or enhancements identified may be best implemented by someone, or another team, other than the originally identified owner. If this is the case then the ‘new’ owner should be consulted with regards to the suggested changes.
5. The suggested changes should be assessed on the basis of benefit, cost and availability of resources to complete the changes. If the enhancement is accepted then the work to complete the change should be scheduled and added to the relevant development pipeline.
6. Finally, the source of the (suggestion) requested enhancement should be contacted with regards to the outcome of their suggestion. It is vital that the feedback loop is complete to ensure that the feedback process continues to be relevant. There is nothing worse than making a suggestion and not hearing the outcome even if it’s not the outcome that was desired. Of course, any suggestion that is rejected should be fed back with the reasons why it was rejected.
I have now completed my articles on the Build to Scale phase of the Centre for Enablement Playbook and have even strayed into the next phase of Measure Impact.
The next article will cover the final element of the Centre for Enablement Playbook and then I can move on to a new subject area.
I can be contacted through:
LinkedIn — https://www.linkedin.com/in/alan-dalley-7701151/
Email address — Alan.mule.mentor@gmail.com
