MuleSoft Catalyst

Centre 4 Enablement Playbook Establishing the Foundation.

Identify Assets to Be Created and Reused Across Initial Projects

In this article I will be looking at the Operating Model (C4E) element of the Identify Assets to be Created section of the MuleSoft Catalyst Playbook. I will present my thoughts on the topics identified in the Playbook and talk about my personal thoughts on the journey that we had in establishing what others tell me is a very successful and well-structured Centre 4 Enablement. Hopefully some of these thoughts will help others to follow the path to success in your organisations. The specific areas to be covered are:

• Enablement vs delivery
• Central repository of reusable architecture and solution building blocks, best practices, APIs, etc.
• Processes to publish, discover and consume integration capabilities.

The structure of the C4E in each organisation will be different. No doubt about this as you will have seen if you have read my previous articles on establishing a C4E. Some C4E’s will have dedicated staff, some may be mostly outsourced and some will be a hybrid of technical and business staff. The options are many and varied. However, regardless of the constitution of the C4E the three areas highlighted above will need to be addressed and the challenges will need to be identified and solved.

Enablement vs Delivery

I have already talked about the main functions of the C4E which in my view are operating the governance surrounding the development and implementation of API’s and the evangelisation of the API led architecture within the wider business. These two elements can be seen in the context of Enablement and Delivery but the understanding is slightly different and I will explain why.

Firstly, let me address enablement. One of main functions of the C4E has to be the enablement of the API led architecture but this is achieved in a number of different ways depending on the audience that you are addressing. Enablement in my experience takes two main streams. Teams within the organisation cannot take advantage of the benefits of API’s if they do not know what they are and the capabilities they can deliver. For the business it may be a case of you don’t know what you don’t know and therefore, for some parts of the organisation you may have to start from the most fundamental aspects of integration and providing the most basic understanding of what an API actually is. Of course for other parts of the organisation they will be more familiar with integration technology but will be unaware of the existence of the C4E or its capabilities. By conducting evangelisation of the C4E and its capabilities you are enabling the organisation to gain the benefits of an API led architecture and delivery of API’s. This is enablement through evangelisation and, I would add, education.

So now let’s think about Delivery. What does the C4E need to deliver and why?

In the organisation in which I work we have a number of different teams both internal and third party ‘partners’ who are developing API’s for different arms of the business. Each group will have different business requirements and different goals but at the basis of all of the requirements there will be a number of foundational assets which will be common to all API developments for example, the ways in which errors are handled, the way in which audit logs are written, common security policies and other functions which the C4E deems should be used by all development teams in order to pass governance standards and be allowed into the production environment. I would certainly make the argument that one of the initial tasks of the C4E will be to identify these foundational assets, define their requirements and supervise their development as soon as possible after the C4E has been established. The foundational elements will enable common development tasks to be undertaken and, when reused, will shorten development times and the time required to pass the governance processes. Thus, a function of the C4E should be to enable development through the delivery of foundational assets. And this leads me on to the second bullet point that I need to address. We are talking about the delivery of foundational assets but where are they stored and how is their existence made known to those teams building API’s?

Central repository of reusable architecture and solution building blocks, best practices, APIs, etc.

It’s important to state at this point that the foundational assets I have described above may have led you to believe that these are all related to API’s and fragments of code which can be used by all development teams across the business. This is not true although the a significant amount of the foundational assets will be code and code fragments there will also be elements of documentation that will need to be available across the wider business and possibly outside of the development teams.

Certainly, for the API and API fragments and possibly other snippets of code a central repository will be required that can be accessed by all developers across the whole business. Luckily MuleSoft provides this repository at the centre of its API development and management offering in the form of MuleSoft Exchange. The existence, purpose and use of MuleSoft Exchange is one of the most important messages that needs to be conveyed to as many people as possible within the business. The MuleSoft Exchange should be the first port of call for all project staff when looking for any data for use within the business. But what happens if the data that a business user is seeking to use is not available via an existing API? There must be a mechanism for the customer to request the development or modification of an API and thus we have one example of a number of business processes which will form fundamental documentation assets within the C4E.

Some businesses will have their own bespoke document management systems and some, such as my own, will use systems such as Microsoft SharePoint and/or Atlassian Confluence. Regardless it is vital that everyone has access to these documentation stores controlled with the appropriate levels of security appropriate to the encumbered level of security and need.

Processes to publish, discover and consume integration capabilities.

Having identified, designed and developed the foundational code and documentation assets we return to where we began — evangelisation but with a slight twist.

Yes we need to evangelise because, as I said above, people don’t know what they don’t know, so we have to get the message out there about the integration capabilities that we are building and, quite possibly, have already built. But evangelisation, going and talking to people and making presentations, delivering websites and seminars etc is not, in my view, enough. Anyone who has been involved in education and mentoring as I have for many years will know that all people learn in different ways. Some people learn through reading, some learn by using visual aids such as drawing and some learn by hands on doing. This element of the MuleSoft Catalyst says we should develop processes to publish, discover and consume integration capabilities. I would suggest that we need to spend time investing in doing exactly this but also conducting workshops, using drop-in clinics and identifying other ways to interact will all members of the organisation as it is only in this way that engagement will provide the dividends that we should seek through use, and reuse, of fundamental building blocks. Education will open eyes to fresh opportunities and drive never before possible innovation within the business.

One last thing that should be recognised here is that the identification, development and production of fundamental assets should not be seen as a one-off exercise. From my experience there are three key lessons in addition to, or as a supplement to, the actions documented in the MuleSoft Catalyst.

Start the process of identifying, developing, testing and releasing foundational assets, including processes and documentation, as early as possible in the lifetime of creating the API led capability.

Evangelisation of the API led capability and the foundational assets including processes and documentation, should, again, be started as soon as possible after their development has started and, in some circumstances, before they may even have been completed.

Lastly, don’t think for one moment that this exercise will ever come to an end! It may slow as the number of fundamental assets grows and covers all parts of the business but always be on the lookout for processes that are getting repeated across the business and may become a candidate as a foundational asset. In addition, review foundational assets including code, processes and documentation on a regular basis. You may be surprised by the number of things that change or require amendment. I certainly was and still am.