MuleSoft Catalyst — Centre 4 Enablement Playbook Establishing the Foundation.

Identify Assets to Be Created and Reused Across Initial Projects

In my previous articles on the MuleSoft Catalyst Methodology I have looked at the Centre 4 Enablement (C4E) Playbook which sits under the Organisational Enablement section of the methodology. In particular I have addressed the Plan for Success pillar of the playbook and its two components under the Plan for Success area — Assess Integration Capabilities and Establish the C4E.

So, with the Assess Integration Capabilities completed and having established the C4E we can start to look at the Establish the Foundation pillar of the playbook which deals with building and publishing foundational assets. In the following articles I will talk about the seven sections of this pillar describing the subject area of each section and the practical issues and advice from my experience of executing the work required in each section.

It is important in this section to remember that we are trying to identify the assets that are to be created, we are not trying to actually build the assets, that will come later! In addition to identifying the assets we will need to prioritise the order in which assets will be built so that we can accelerate the delivery of value to the business whilst at the same time building assets that are reusable going forward.

As well as identifying these reusable core benefits, we should look at the establishment of best practices in order to establish good working practices right from the commencement of delivery. Documentation of common business practices and ways of working at this stage will deliver the foundations of the C4E going forward. I have found that, in addition to identifying reusable assets, it has been important to establish mechanisms which will allow the C4E staff, associated business groups and development groups to feed back into the C4E, areas of requirements and concerns that may, and have done in my case, alter the priority of asset development. It is highly likely that the C4E will not know all of the different innovations, project developments or business goals across the organisation and therefore lists of priorities may change as new information emerges.

The playbook describes fifteen areas that should be considered when thinking about the C4E reusable asset list each of which deserves more discussion than the simple provision of the list. For this reason, I will tackle the first two bullet point in this article and address the following sections in separate articles.

For completeness the fifteen areas suggested by the playbook are:

1. Introduction to composability / API-led connectivity

2. Application networks

3. Operating Model (C4E)

4. Integration Principles

5. Integration Best Practices

6. API Best Practices

7. Deployment

8. Continuous Integration

9. Test Automation

10. Agile Delivery

11. Operations

12. Business Organizations

13. Asset Repository

14. Governance

15. Evangelism

So, let’s start with the Introduction to composability and API-led connectivity. In this section we look at the four key areas of:

• Ownership and lifecycle
• Benefits of composability
• API-led connectivity vs traditional SOA
• Definition of Experience, Process, System APIs

So, addressing the first issue, we need to look at ownership of the assets that we will be developing going forward and the lifecycle of these assets within the organisation. It’s important to remember that these assets will be designed to be reusable and therefore ownership must be defined and enforced to ensure that API’s continue to be reusable across their lifetime within the organisation. No user of an API should be under the impression that they ‘own’ the API and no one else can use it. Nothing should be further from the truth.

It should also be remembered that we are talking assets here which may assets other than API’s themselves. There is no getting away from the fact that Policies, standards and guidelines must be considered in this category.

Each type of asset will have its own lifecycle with creation, versioning, deprecation and retirement being part of each asset types lifecycle over time.

Composability is at the heart of API development and use. Wherever possible, and I think there would have to be a very strong case if this were not so, API’s should be envisaged and designed to be reusable. The benefit case for this should be obvious but still stated.

Where an organisation has a SOA capability alongside which API-led connectivity is to be introduced then the organisation needs to make some possibly tough decisions. Will API-led connectivity be introduced alongside the SOA capability, or will SOA capability be removed from the organisation over a period of time? The elements of this discussion are very specific to each organisation and therefore too complex to address in this article as organisational considerations need to be addressed as well as technical decisions that, in some way, are more straight forward to answer.

The three-layer API architecture is at the centre of the MuleSoft offerings and, to people familiar with integration architecture as a whole quite obvious. However, one of the most regular questions I am asked by business users and sometimes by colleague is what is the definition of each of these types of API? Trust me definition of each of the three layers of the API-led architecture will save you a lot of time if you can reference some documentation. For our implementation this was placed in a prominent place on our website. Do it, you won’t regret it!

Application networks

• Reuse of integration services and building blocks
• Composable integration solutions

One of the main benefits of the API-Lead Integration approach from both a development time perspective, cost perspective and data quality perspective is to built application networks using the reusable components that will be identified in this part of the MuleSoft Catalyst methodology. It should always be born in mind that assets being identified here, and developed in later stages of the Catalyst, will be used as building blocks for application networks. Reuse is paramount to everything that is identified at this stage in the work you are undertaking.

In the next article I will address the Operating Model for the C4E and provide some, hopefully useful, insights to the journey I had in this area.