MuleSoft Catalyst
Centre 4 Enablement Playbook Establishing the Foundation.
Identify Assets to Be Created and Reused Across Initial Projects
In this article we are still in the world of looking at the creation of reusable assets while implementing the Centre 4 Enablement. However, we have reached the point where some of the decisions to be made are very high level, require technical input and require some fundamental organisational decisions to be made. We come to the point where we make the decision on what type of MuleSoft Deployment we are going to implement and work with going forward. It’s not the end of the world forever decision, but it will have significant and possibly very costly implications if you get it wrong. However, some paths, if taken consciously at this point can form a roadmap to transition from one implementation to another when time and budget allows. I am not going to go into details on how you make this decision, it could be the subject of a much longer article, but I will outline the different options as defined in the MuleSoft documentation. If you want to read the full details you can find them here
Deployment
The following descriptions on deployment options are taken from MuleSoft documentation and are placed here as a brief summary of each option.
Cloud
CloudHub is a complete integration platform as a service (iPaaS) that provides server functionality for you to deploy your apps from the Runtime Manager cloud console without having to configure a hosting environment. Based on your contract, you control how many resources to assign to your application.
Hybrid
With the hybrid deployment option, you deploy your apps from the Runtime Manager cloud console to your Mule servers and use Runtime Manager to manage them. This option provides you with flexibility and control over your on-premises security but requires you to provide the hosting infrastructure.
Private Cloud Edition (PCE)
Anypoint Platform Private Cloud Edition is a containerised distribution of the management and engagement capabilities of Anypoint Platform that you host on-premises or in your organization’s private cloud environment.
If your organization has strict regulatory or compliance requirements that limit the use of cloud solutions, you can use Anypoint Platform PCE to deploy and host your apps on-premises.
Runtime Fabric (RTF)
Anypoint Runtime Fabric is a container service that automates the deployment and orchestration of Mule applications and API gateways. Runtime Fabric runs within a customer-managed infrastructure on AWS, Azure, virtual machines (VMs), and bare-metal servers.
Runtime Fabric contains all of the components it requires. These components, including Docker and Kubernetes, are optimised to work efficiently with Mule runtimes and other MuleSoft services.
To use the Runtime Fabric option, you first create a Runtime Fabric using Runtime Manager. Then, you install Runtime Fabric on your infrastructure. Finally, you deploy your applications from the Runtime Manager cloud console to the Runtime Fabric you created.
Other Topics
There are three other topics mentioned in this area, automated provisioning of runtimes, Virtual Private Cloud (VPC) Setup and Load Balancing. These are technical areas which require discussion with Integration and Platform Architects in your organisation and while I am fortunate enough to have passed these MuleSoft certifications I don’t believe I should go into too much depth when talking about the C4E playbook and establishing the C4E in this respect. Detailed documentation on all of these topics can be found in MuleSoft documentation on the Internet.
Continuous Integration
Now, the next topic on the agenda is discussion on continuous integration which is a topic that I am able to offer some advice on through the experience that I have had setting up the Centre 4 Enablement that I lead within my organisation. Here we need to cover the three areas defined in the playbook, processes, tools and teams.
Processes
The IT industry thrives on processes and many organisations that I have worked in have developed processes for almost every aspect of the work they undertake. Of course, some organisations need rigorous processes because of the work they are involved in and the data they are working with, prime examples would be drug manufacturing, banking and defence from my experience. However, we need to address the types of processes that you will need to think of when setting up the Centre 4 Enablement so let me address some of the key processes that I have worked on in this respect.
When developing API’s you will work with a number of projects that will appear at your door over time. The first process we worked on was a process to on board new projects in order to standardise all of the aspects of API development that we needed each project to be aware of including: -
Working Agreements — What the project could expect from us and what we expected from them. Signed by the project manager to ensure they had read and understood the commitment on both sides. The important thing here is that the working agreement outlines the overall process that will be undertaken by both parties during the development of the API’s whether that be packaged delivery of each API in turn or, as is our case, the use of Agile ways of working to deliver the required API’s
Design Governance and Code Governance processes and expected timescales are key to the foundations of the Centre 4 Enablement. The process will include: -
Document templates to be used.
Timescales for submissions.
SLA’s for review and response.
Actions on rejections.
Attachments to be included.
Cost recovery processes (if you are charging for development and/or use of API’s). Cost recover could include: -
What API’s will be charged for and when the cost will be recovered?
How costs would be recovered — by Capex or Opex
How costs for the use of API’s will be identified and charged for
How and when support costs will be recovered
But there are many other processes that will be useful and must be considered when establishing the Centre 4 Enablement. In order to provide some idea on the areas that you need to consider I would suggest that you think about the following.
How will you engage and work with your IT Security team. Do you need a process for identifying security updates and incorporating them into the C4E governance checklists?
What process will be used to ensure ongoing funding for the C4E?
How will you monitor the central development function, if you have one. Do you need a daily stand-up process if you are operating Agile ways of working? Do you need to report on KPI’s for the C4E?
Do you need to engage with HR processes for time recording or annual leave reporting or do you need your own processes for this?
If you are working with third party suppliers what processes does the C4E need to develop for this engagement?
If you are working in a highly regulated industry what processes does the C4E need to develop and operate to ensure that it is compliant with the appropriate regulations.
As you can see by now there are many processes that need to be considered, developed, trialled, implemented and monitored and I hope this has generated some thought in this area.
Tools
Another one of the first considerations when establishing the C4E is the toolset that will be used to create, operate and monitor the API development capability and specifically the C4E. Looking beyond the obvious Office capabilities such as the standard Microsoft Word, Excel, PowerPoint etc. or equivalents we need to consider the development methodologies that are in place within your organisation unless you have the ability to ‘break-out’ to new ways of working. If you are operating in an Agile environment whether that be Scrum, Kanban etc. then you will probably need a tool such as Atlassian JIRA / Confluence to record and manage requirements and hold documentation of course there are other options out there. In addition to a requirements management tool the major decision is the API Development tools beyond the MuleSoft Platform itself. Some organisations will no doubt use Azure DevOps which is an excellent choice however for others you may need to consider a set of tools such as Github, Maven, Jenkins, SonarQube etc. There are many choices available and careful consideration will be required to determine what works for you and your organisation.
Teams
Depending on the size of your organisation and specifically the C4E you will need to consider the people you have available to you, their skill sets and how to break the people and skills into teams to get the most effective use of your resources. Some organisations have fairly large teams to operate their API development capability whilst some manage to establish well organised C4E with a minimal staffing level.
Some roles required may be highly skilled and require MuleSoft certified people to properly manage an area while other areas of the C4E require skills that do not directly relate to MuleSoft such as a Service Delivery Manager or project support staff. Of course, this does depend on your overall view of what is, and is not, included in the C4E and this will be dependent on each organisation.
I would suggest that a good structure to a C4E, and possibly the surrounding support roles would be: -
While the C4E Lead probably doesn’t need to have all of the MuleSoft Certifications required by people in the other teams I have found it useful to obtain the Developer, Platform Architect and Integration Architect certifications in order to understand the challenges in each area. In the Governance team I would definitively sub divide this into Design Governance and Code Governance and have one, or more, people who are certified Integration Architects and certified Developers respectively.
In the CloudOps team you will require a person with Platform Architect certification and possibly other Cloud certifications such as AWS or Azure depending on the Cloud facilities that are in use. I would strongly suggest that all developers in the API development team are MuleSoft certified developers and people in the API Support function will probably, as a minimum be the same.
DevOps people, I would suggest do not necessarily need to be MuleSoft certified although it would help but they do need to be intimately familiar with the DevOps tools in use within the DevOps environment.
As a final point I would suggest that each C4E, really early on in its existence, needs to determine the number and types of resources it requires for the organisation it will support as this will influence recruitment and training plans going forward. As a minimum and to put yourself on a firm foundation you need to have experienced integration staff in place supported by people with knowledge of the business at the start of the C4E. Remember if you don’t have people immediately a short-term engagement with MuleSoft professional services may be something that you want to consider.
