MuleSoft Catalyst — Integrated Blueprint
How to demostrate progress when implementing a MuleSoft capability
If you have read my previous articles then first of all, thank you ,and I hope you found them helpful. I must now progress, as promised, to the MuleSoft Catalyst Blueprint.
So just as a quick reminder or to set the scene for people who have not read the previous articles, the MuleSoft Catalyst methodology has playbooks and delivery approaches and is founded on three pillars, Business Outcomes, Technology Delivery and Organisational Enablement. Each of these pillars has four phases attributed to them Plan for success, Establish the foundation, Build to scale and Measure impact. Within each phase the Catalyst describes Activities and steps that need to be taken in order to achieve a successful implementation of any of the MuleSoft products. Now at this stage its worth emphasising, if you had not seen this before, that the MuleSoft Catalyst and the Knowledge Hub do not relate only to the MuleSoft AnyPoint platform. Its covers all of the MuleSoft products available as it is a methodology not a specific implementation of a specific capability.
When you are in the depths of an implementation project, and I have been there in recent years but thankfully now into successful operational status, its easy to get down in the weeds and wrapped up with the tasks that need to be done on a day-to-day basis. But you can bet that at some point, or numerous points depending on the organisation you are working for, you will be asked where you are on your overall journey from start of implementation to a fully operational capability. This is where, if you plan it carefully, the MuleSoft Integrated Blueprint can become your best friend.
Now, if you take the material from the knowledge base you are going to start with something that looks like the diagram below.
The Knowledge base, as I have written about in many articles, contains a lot of collateral assets that you can use to manage, monitor and control your implementation but the key here is to link the steps in the playbooks and the output from the delivery approaches to the high-level picture that is shown above. Unfortunately I can’t give you the magic potions and formula’s that will allow you to do this because it will be individual to each and every organisation but you will have someone in your organisation that can build a dashboard either in Tableau, Power BI if you are a Microsoft Power Platform User, or even plain old Excel that will allow you to take the grass roots progress reports and take these up through, I would suggest a limited number, of reporting layers to allow you to report progress at the very high level required by the Integrated Blueprint. If you can do this, maybe as one of your foundational activities (Establish the Foundation Phase) then this will not only assist you in monitoring the implementation of the capability but will also make ongoing operational reporting (Build to Scale and Measure impact Phases) much easier.
Now while I am referring to ongoing operational reporting it might be the time to look at the above diagram in respect of the delivery phases of the introduction of the capability.
I hope I can make this clear. In delivery terms the Plan for success phase, activities and steps along with the Establish the foundation phase, activities and steps constitute the Launch of the capability. Its important to recognise that the work in each of the three pillars will not progress at the same rate although the work can be undertaken in parallel if you have sufficient resources in each area. However, if you look at the work required you will, hopefully, see that there are some dependencies, e.g. you will have to define the platform vision and roadmap before you can implement the platform, which cannot be ignored. If you look at the Catalyst Knowledge base assets for this activity you will find that the Integrated Blueprint diagram has a progress bar on each Activity within the appropriate phase. This is obviously one way of showing progress at a high level but many other ways of showing progress are available and I would suggest that you keep to the method that your senior management is familiar with in order to maintain clarity.
Following the Launch activities the next delivery phase is Scale but I see the boundary between Launch and Scale as being somewhat blurry. In my view, at this stage before you proceed to scale in each of the pillars you need to pause and review where you are.
The activities in each pillar for the Scaling work will depend, I have found, on the lessons learned at each stage of the Launch. As an Agile coach, as well as a MuleSoft Mentor, my approach has always been to Plan, Design, Build, Test and Review. Carry on with what works and change what doesn’t work and I believe that the same is true here.
For the Business Outcome pillar you definitely need to review what your definition of success looks like. This needs to take into account all of the normal project concerns such as finance, staffing, training and support to mention a few. By the time you come to scale you should have a good idea of what your capability looks like and what you need to move forward. Review the overall success plan now to see what you want the future to look like. Having a vision of the desired business outcomes is vital in order to focus the activities in the other two pillars.
In your Technology Delivery pillar you will have the platform up and running and some things, such as where you have deployed the AnyPoint platform for example, will have been fixed, other aspects may be more fluid such as the projects currently running and those yet to be undertaken.
By now, as an example, if you have implemented the MuleSoft AnyPoint platform you will know the number of vCores you are using but you will need mechanisms to predict when you will need to buy more. These can be crucial business decisions with significant financial impact. In addition, remembering that the Catalyst Methodology promotes a separation of platform from project and a decentralised model for development, the onboarding of additional teams may require you to look at resources, training and the establishment of governance process to establish and protect the platform and its operational and support capabilities. These can be complex decisions and the building of the foundational assets such as design standards, coding standards, DevOps pipelines and security policies will start to pay dividends as you scale the platform.
One of the most important activities during both the launch and the scale phases is communication and evangelisation. During the launch phase it is vital to communicate with the rest of the organisation what you are doing and to build interest and enthusiasm of the innovation that integration can bring to the business. The business will want to start thinking about how they can change their ways of working, how they can drive the business forward and what additional opportunities the integration capabilities can bring. On the technical side IT colleagues will want to understand what they can do to help and be engaged with the project. Some teams will need to prepare to deliver assets in the decentralised model that Catalyst encourages so may need to look at recruitment, training and the build of support processes within their areas.
Evangelisation, as I hope you can see now, is such an important area in the scaling of the delivery so you need to be prepared to answer everything from very basic questions right through the whole spectrum to detailed and complex questions about every aspect of the capability.
One last word on scaling. If your capability is successful in its launch and scaling starts then scaling should never stop. The period in which you can refresh your overall success plan may shorten or lengthen depending on a certain extent to how your business grows and how it is financed, your platform will always need to be expanded to support new business requirements and the traing of staff will become an ongoing activity both centrally for the C4E team and for the decentralised teams that are enhancing the offerings of the platform.
The final activity represented in the Integrated Blueprint is Optimise which covers the Measure impact phase. Again, how you do this will be very specific to your own business. I could provide details of how this was done in the implementation of the AnyPoint platform that I was involved in but this would certainly be completely different to your own. How a business measures value or assesses the impact of the platform and projects will depend on many different and widely varying criteria. The important thing here is that you do look are measuring value and you do look at this, not only from an implementation point of view but also as an ongoing activity.
In conclusion then I have looked at the MuleSoft Catalyst Integrated Blueprint which relates to the implementation of any MuleSoft capability, in my case the MuleSoft AnyPoint platform and its capability in the development, management and support of API’s. The Blueprint, as I have hopefully explained, is a high-level view of the progress of the implementation of a capability. Underneath the high level view you may do well to construct processes to measure KPI’s at a lower level and feed these up to the high level summary for senior managers. This will provide ongoing benefits as high level information, in my experience, always lead to detailed questions you will need to answer.
For some implementation the Integrated Blueprint may stop when the capability enters production status but the activities around scaling and measuring should not, and will not, stop if you make the launch a success.
