MuleSoft Catalyst — Enable C4E Core Team
In this article I am going to look at the C4E Core Team and some of the key elements that make up the C4E. As I have explained in previous articles there could be many different organisational structures for the C4E but generally they break down into three main categories of Central, Federated and Hybrid. However, this article is going to examine the two key aspects of the C4E:
Skills required for C4E staff.
How the C4E interacts with other parts of the organisation.
For the C4E to be an effective element of the API Lead strategy within an organisation each person within the C4E must, as a minimum, be fully familiar with integration concepts, platform operations, whether this be in the Cloud or on-premise implementations, application delivery and API lead connectivity. While these are minimum requirements the MuleSoft C4E could not effectively operate without a core of staff that have a complete operational understanding of the MuleSoft platform and possess the MuleSoft certifications to support the role they are undertaking. At this point I return to the C4E structure as MuleSoft certified staff may operate either as part of the C4E or in a federated or hybrid manner however it would be expected that DevOps staff would have the MuleSoft Certified Developer certification, people operating the platform would be expected to obtain the MuleSoft Platform Architect certification and the Integration Architect would have the MuleSoft Integration Architect certification.
Each organisation should look at the organisation it believes will drive the best value, allocate people to the organisational structure and then decide of the education and training that is required for each individual. Reference to the MuleSoft training website will be required to identify suitable course s for each role and at person fulfilling those roles. MuleSoft training is in the process of moving to the Salesforce Website https://trailhead.salesforce.com/ but I believe both sites are still in operation at this time.
One note worth making here is that unless there are people with MuleSoft experience already in the organisation then support will normally be required from either a third party, the contract market or MuleSoft professional services at least for an initial period.
So, having talked about knowledge and certifications let’s look at what drives value from the C4E enablement.
At a basic level the C4E acts as a consultancy group with five main arms as defined by the paybook. These five arms are:
1. Strategy
2. Governance
3. Opportunity Identification
4. Delivery Management
5. Practice Development
If you look at the Catalyst playbook these sections are presented in a different order but I believe that I need to address them in the order above for reasons which should become clear below.
Now, I come from an Architecture and Data Governance background which, by the way, I think is an excellent background for a C4E lead, so the first element I want to look at is Strategy.
Strategy
For most organisations, I would say, there are four main drivers for the introduction of an API-led strategy. Certainly, I have seen a number of organisations that have a spaghetti model of Point-to-Point interfaces to the extent that support and configuration management have become a nightmare to manage. The introduction of an API-Led strategy will, after some time, mitigate this issue whilst also meeting the strategic objectives of reducing the IT footprint for system integration, reducing the costs in connection data to the customer whilst providing a faster time to market and increasing the organisations ability to innovate and use data in ways that the organisation had not previously envisaged.
Once the strategy has been defined the other four elements can be addressed at an operational level.
Governance
While governance must operate across the whole of the API development lifecycle it is important that the atomic elements of the governance process are developed and implemented as early as possible following the establishment of the C4E. Failure to do this may lead to the development of API’s that will be promoted into the Production environment without meeting the required C4E standards. This will inevitably lead to technical debt which will need to be addressed at a later date.
Some of the fundamental elements required are Design standards, against which each API design must be assessed, Code standards against which API code must be assessed, preferably by an automated tool to reduce manual effort and the processes that are required to implement the Design and code reviews. These processes will need to be dovetailed into the DevOps and CloudOps release processes which protect the Production environment and ensure that the required level of quality and, importantly, reusability of the API’s is maintained.
The remaining three elements in this section are the pillars that are supported by, and implement, the deliverables of Strategy and Governance.
Opportunity Identification
In this section it may appear that opportunity identification is within the realm of the business and, indeed, this is the case however it also lays fundamentally within the scope of the C4E especially where strategic opportunities can be identified. Every organisation will have the base or Systems of Record, type systems which contain the data that supports their business. Typically, this will include systems such as HR, CRM, Accounts payable / receivable etc. Unlocking this data at a system level through the use of System API’s can be seen as a function of the C4E. With the identification of API identification comes the responsibility to prioritise the development of these API’s and aligning the development with the priorities of the business as a whole. Of course the business will want o see what return it is getting for its investment in what we already know is a relatively expensive platform so alignment with the organisations PMO may be a requirement in some organisations.
It should be remembered that wiles the C4E will be the governing body for API development it is also a development capability in itself which must display the highest level of development as an example to all of its customers.
Delivery Management
Whichever implementation model has been used to establish and operate the C4E there will be a development capability associate with the C4E. The model that I am most familiar with is a Central Development team and a number of, what is referred to as, Self Service Teams operated outside of the central C4E structure.
Regardless of structure a recognised development pipeline will exist with more and more organisations implementing Agile and DevSecOps development pipelines. Of course, the C4E will need standards for whatever method and tools are being used. Hopefully that goes without question now!
Delivery Management will be responsible for the capture of integration requirements to support a business integration, the conversion of the requirements into an API design and the development of the API, s required to perform the business integration. Quality assurance will be maintained by the C4E Design and Code governance supported by defined DevOps and CloudOps process to get the API’s deployed into production.
One element that needs to be well defined, especially where multiple teams are delivering API’s from across the organisation, is the processes and procedures required to maintain and support the delivered API’s. This could involve the team that developed the API’s, or it could be a central support function. Of course, if it is a central support function these people will need to have the skills to support MuleSoft API’s and will need to have a full and comprehensive handover of the API’s from the development team.
It should remembered, and I can’t emphasise this enough, all API’s should be designed and constructed to be reusable across the organisation. The whole point of an API lead integration is to drive reusability rather than use a platform like MuleSoft to perpetuate the development of Point-to-Point interfaces.
Practice Development
Finally, we come to the development of the Integration practice. I think a lot of people, especially if they have read my previously articles, will understand that one of the prime objectives of the practice development is evangelisation. If you have a capability like MuleSoft within the organisation then you want everyone in the organisation to know about it. The benefits and capabilities of MuleSoft are immense but the organisation won’t know what they can do unless someone tells them. That someone is the C4E!
So, once you have told the business what the possibilities may be you need to give them examples of what can be done, what you are doing and templates for them to follow in your footsteps. And you need to maintain those templates, review and improve your best practices and check to make sure that the Software Delivery Lifecycle continually grows where required.
The C4E team has a lot of responsibility for ensuring that they are providing the best example of integration development that they can. It’s also a continual process to ensure that the standards, code fragments, process and toolset are kept up to date and can set an example to all projects that may be developing API integrations.
In the next article we will start to look at, and breakdown, the work that the C4E needs to do in the form of creating a backlog for the C4E
