MuleSoft Catalyst — Establishing the C4E
Let’s get into the process of establishing the C4E.
Up to now we have spent time in assessing the integration capabilities of the organisation and thinking about how we are going to make the transition to a MuleSoft integration ecosystem We have looked at the IT organisation, the business we are working within, who we need to talk to, how we get them on-side with what we are doing and then thinking about the Programmes, Projects and processes we need to create or change. One of the activities we looked at was committing to the C4E. Well, we have done that so now we need to get going and the first thing we have to do is define what the mission and charter is for the C4E. I thought long and hard about this and the definition went through a number of iterations but here are some of the lessons I learned and some of the outcomes. I’m afraid that this may be a bit of a long article but please bear with me as it really is a key area to get right and hopefully there will be useful content right through to the end!
There are two things to say up front about this activity which are really important.
Firstly, the mission statement will be very dependent on your own organisation and may look very different to the elements that I will discuss. You will need to take into account all of the investigations and lessons that you have learned from the previous stages of the Centre 4 Enablement playbook. If you have not read my previous articles then I strongly encourage you to do so now.
Secondly, MuleSoft, as part of the playbook, provide a C4E Charter Template for us to use to develop our own Mission and Charter statements. I would recommend that you have a look at this document to get you started. I used some of the suggestions but others didn’t fit with our organisation so, as with everything, use this wisely.
The first consideration for the charter is to produce a mission statement. I have to be honest and say that I am not a great fan of mission statements as, in my experience, they are either too brief to encompass the area they are supposed to cover or they become so long that no one wants to read them. However, on the beneficial side they do focus the mind on what you are trying to do so I did spend quite some time thinking about this and then revised the initial draft as I went through and completed the other sections. My advice would be to revisit the mission statement after each of the following sections have been completed and to keep to either a single paragraph or a limited number of bullet points. The aim being to convey to the reader a concise picture of what the C4E will do, the capability it will provide and the benefits that it will bring to the business.
If you find it useful the template provides for a C4E Overview however we chose not to include this in the charter but to provide some more in-depth content on our C4E page on our website. There were really two reasons for this which were the desire to keep the charter to a summary document but also to provide more information, in a more readable format, at a location that would be available more widely across the business. We were conscious of the fact that we wanted the information to be available to both IT and Business users and in a more readable and immersive format that just paragraphs of text.
It was for the same reason that we now decided to deviate from the suggested format given by the template. We did cover all of the headings provided by the template but in a different format as I have alluded to above. So, for clarity I will describe the approach that we took in some more detail.
Remember the Overview is gone to the website so now we are left with the Objectives, Business Benefits, C4E Services, Operating Model, C4E Roles, Measuring Success, Training and Certifications, Stake holders and Risks, Constraints and Dependencies. Having reviewed all of these proposed sections the consensus was that for some of the elements that we felt would not change significantly we were prepared to cover these with bullet point lists, for others we considered them to either be too volatile to include in a bullet point list or warranting too much narrative to allow them to be included in the template that was now coming to mind and is shown below. It now became clear that this output would be a summary document that could be equated with a management summary or a one stop reference point for IT and the Organisation to use in presentations around the organisation.
I offer this template to focus the mind on what you might include in these headings and in the hope that it points in the right direction. I have to say from personal experience that this was a difficult but very rewarding exercise, conducted over a relatively short period of time, in order to gain consensus amongst the C4E team members and other senior managers that may have an input to each area. As in all things you probably won’t get this right, or even complete, the first time round but because it is a concise template you can revisit it often when questions arise.
There is no way that I can provide the contents of each of the sections of the template, but I suppose it may be useful to provide some very brief guidance to get you started in each area.
C4E Mission — Each organisation will have their own reasons for embarking on the MuleSoft journey so each organisation will have their own Mission Statement. Some could be related to the establishment of an API Lead Architecture, improvement in data sharing and reuse of API’s and some organisations may be looking to improve their ability to innovate in their business using timely and consistent data. Others may be facing the spaghetti hell of point-to-point interfaces and have approached the point where support and change management of these interfaces has become untenable. Each organisation will have its own challenges.
Benefits
As I have said before the MuleSoft ecosystem is not cheap, and would not pretend to be so, and therefore any implementation must have benefits to the organisation which may include reuse of API’s, shorter development period for projects, increased data quality, increased collaboration across the business along with a reliable and dependable platform for the development and management of API’s.
Business Outcomes
Of course related to the benefits will be the Business Outcomes. These outcomes may include a quicker time to market through the reuse of data, innovation delivers possibilities that were not possible prior to the introduction of API’s and many other outcomes depending on your line of business.
Objectives
Objectives can be taken directly from the MuleSoft template and used with some minor amendments to make effective statements. But don’t just copy and paste the narrative. If you do you will find yourselves coming back to them again and again. Best to consider and debate whether they are right for you.
And so we come to Team Enablement, Platform Services, Education and Governance.
Team Enablement
Team Enablement will very much depend on how the team is constructed and so it’s very difficult to give any guidance other than to say you may have a completely permanent resourced team, maybe you will have recruited some experience contractors, you may be very lucky and have MuleSoft Professional services on board (thoroughly recommended as I have said before in previous articles) or you may be working with one or more third parties. Or, of course, a combination of any of the previously mentioned groups. You have to find the team(s) that work for you and decide how people are introduced to the team, how the team operates on a day-to-day basis and also what happens when people leave.
Platform Services
Platform Services will consist of a number of areas and will be one of the easier sections to complete once you have decided the initial configuration of the platform. Now I said one of the easiest, which is a relative term, I didn’t say easy as it may not be. So, you have purchased and installed the MuleSoft Platform either on the Cloud or On Premise and with a defined configuration depending on your requirements. So the service provided are centred around maintenance of the platform, Upgrades when they occur, Security and documentation. There will be more but what is contained here will again be dependent on your implementation.
Education
Education will be related to the combination of people in the team(s). Some may already have certifications from MuleSoft, some may require training and some may like post certification education and mentoring. In the education section you will need to define the level of education for each role in your team and how and what the organisation is willing to fund.
Governance
And so we come to the last element of the template shown below. Governance is a major are of the C4E and will govern areas such as the production of standards to cover such areas as Design templates, Code development, Security guidelines and other organisational governance requirements. You may define in here governance gates for design and code and KPI’s for tracking the quality of documents and code. Each organisation will have its own governance requirements whether they be financial, security or from a governing body such as the DfT, FSA etc
The remaining sections of the MuleSoft template that are not covered by the table above now need to be addressed. Each of these sections, in my view, requires a document in their own right and were therefore not included in the template.
Operating Model
The Operating Model is the first area where the content will be very unique based on the organisation and may be presented in any number of formats. It is possible that the information required in this section not only shows the people directly engaged with the MuleSoft team but also needs to show where they sit within the business in terms of their managers, Agile Teams and possibly other lines of reporting. But, it is not enough in this section just to represent the team. In fact one could argue that it is more important to show the functions that are involved, what their areas of responsibility are and how they can be engaged to fulfil their role.
One fact to bear in mind with this document is that it is a fact of life that people will move on both within and out of the organisation as careers progress but the function that they are undertaking will remain. If you want or need to include names in this document then it should be reviewed on a regular basis to ensure its releveance.
C4E Roles
The MuleSoft template provides a number of suggested roles to populate the C4E along with responsibilities, skills required and their seniority in the company.
It is likely, almost inevitable, that you will need to write Job Descriptions for these roles even if the people occupying the roles have already been identified. But, as before, the important part of this document will be the roles that you want to create and the Job Descriptions for those roles rather than individuals. A word of warning, some organisations may not be familiar with Integration type job descriptions and may not therefore assign the correct level of seniority and reward to the Job Descriptions you present to them. Be prepared to fight with them as this may have a significant impact on your ability to recruit the type of qualified people you will need to operate the capability efficiently.
While a lengthy document, mainly made up of Job Descriptions and responsibilities, once complete, should not need to be revisit on a regular basis unless the organisation fundamentally changes in either its size or organisational function such as moving from Waterfall to Agile development.
Measuring Success
Developing the metrics for success may, at first, seem like a simple task but this turned out to be far from the truth as measuring the success of the C4E is intrinsically linked with the business users that are using the API’s being developed by the capability. A conundrum arises where success is partly, at least, measured by the business rather than the C4E itself. However, as always there will be ways of measuring success but they will be dependent on the roles and responsibilities defined for the C4E. As an example, if the C4E is responsible for design and code governance then one of the metrics may be how many designs pass the governance process first time and another may be how many code reviews pass governance first time. These are just examples and each organisation must measure their own success based on the structure and roles performed by the C4E
Stakeholders
Stakeholders will, I would suggest, come from a number of areas of the organisation both IT and within the business. You will be operating a Platform and providing a capability across the organisation which will involve infrastructure, networks, Lines of Business, Management and possibly even external bodies.
Stakeholder lists will need to be reviewed and revisited on a regular basis to ensure name, roles and contact details are kept up to date.
Risks, Constraints and Dependencies
While the MuleSoft template contains the three headings of Risks, Constraints and Dependencies I would suggest that a normal RAID (Risk, Assumptions, Issues and Dependencies) Log may suit the purpose just as well and would be more recognised within most organisations.
The RAID Log turned out to be something that we refer to on a regular basis following its initial development. An Excel Spreadsheet will normally fit the purpose unless you have a RAID tool that is easy to manage.
I don’t think I need to say too much more in this context.
If you made it this far through the article then I hope you have found I interesting and useful. The article is long but hopefully some of the guidance here will help to make your journey easier as you look to establish this capability that will, I assure you, provide significant business benefit for all if you get it right!
