MuleSoft Implementation

Where do I start?

Recently I was asked the question “If I am implementing MuleSoft AnyPoint platform in my organisation where do I start?” Well, it’s a very good question and I will give some of my views from the lessons I have learnt whilst undertaking this very task.

The three pillars that are set out by the MuleSoft Catalyst methodology are a very good place to start your thinking when you are planning this work. Primarily you have three pillars to consider as set out by the MuleSoft Catalyst Methodology

1. Business Outcomes

2. Technology Delivery

3. Organisational Enablement.

I have written about each of these in detail in other article so I won’t explore them at that level here other than to say you will need to consider a number of factors right at the start of your journey. So where do we really start, what might seem, a mammoth task.

To be philosophical each journey must start from the place where you are now. In this case your first step is to fully understand your current organisation, its current capabilities, technology, finance and resourcing plus, most importantly the strategy going forward and the desired outcome. You need to know where you are aiming and how you are intending to get there. That’s your starting point. You can’t really start a journey unless you have a destination otherwise you are heading out in the outback and we all know that is never a good place to be.

So, beyond there what are the next steps? Well, probably two or three key decisions need to be made some of which may be straight forward given the discovery of your organisation and some that may require more consideration. Always remember though that the aim is to meet your business outcomes and you should always keep that in mind and check you route on, what may be, a not very direct path for where you want to be.

There will always be challenges and success depends on living, learning and moving forward.

Now, the output from the Business Outcomes playbook may be your most important foundation but you should always remember that organisations never stand still if they want to survive and be successful so plan to review this at regular intervals. However, there is a fairly clear choice with regards to the MuleSoft Runtime engine. You can have one of three options which are broadly:

1. Cloud based as Integration Platform as a Service (iPaaS)

2. Hybrid — where you have management capability in the Cloud and run API’s from your own infrastructure

3. Private Cloud Edition — both management and runtimes on your own infrastructure.

I think it’s probably fair to say that in the majority of cases the choice is fairly clear cut and depends on your organisations strategy towards Cloud based Systems, Regulatory or Compliance commitments and approach to security. This is probably, as I say, one of the easiest decisions to make.

Whichever way you go, in my view at least, the next two decisions that need to be made are around what your Centre 4 Enablement will look like and on a slightly wider aspect how are you going to manage the platform as a whole. These decisions will be very much based on the discovery from your Business Outcomes investigation. Let’s explore this is more detail and see where the MuleSoft Catalyst and the real world may differ. I have said it more than once but it’s worth saying again, the MuleSoft Catalyst is a very good methodology based on extensive experience across many industries but it is not, and no methodology can be, a panacea for all occasions. You have to use it intelligently.

The MuleSoft Catalyst will tell you that the Centre 4 Enablement is a decentralised, cross functional, group focussed on reuse and development of best practices across all IT projects. In a lot of organisations this model will work well and will allow many talented people to become enthusiasts and evangelists for API’s which is great. But this doesn’t work for all. As an example, if your organisation has little development skills in house and relies on third party alliances or you have limited resources of skilled people in API development it may not be possible to have a decentralised Centre 4 Enablement. This does not mean that that you cannot have a very effective Centre 4 Enablement that can meet the core tenets of the Centre 4 Enablement responsibilities. It does mean, however, that the reliance on your teams that support the C4E may be greater and require a diverse set of specialised skills.

Keeping the above in mind let me look at the roles, either centralised or decentralised that will be required to efficiently and effectively operate an Integration capability using the MuleSoft AnyPoint Platform. Just to mention that I will not be looking at line management responsibilities with these roles as this will very much depend on each organisation.

Let me start by looking at the two key elements which must run side by side and support one another very closely. One will have a technical bias and the other an operational bias.

No points for guessing that the technical element is the Centre 4 Enablement. Now I am not saying here that the C4E has to have specialised technical skills but it will help considerably if it does. If the C4E staff do not have technical skills then they will need access to people who do. If you follow the Centre 4 Enablement Delivery approach and use the Centre 4 Enablement playbook provided by the MuleSoft Catalyst one of the first activities you will do is draw up a mission statement — what is the purpose of the Centre 4 Enablement, why is it being established and the business aims of the team. Think long and hard about this mission statement as it will direct the structure of the Centre 4 Enablement and act as the foundation of a number of other decisions that you will need to make.

The Centre 4 Enablement could consist of various roles depending on the mission statement and the line management structure may be either centralised or federated however the Centre 4 Enablement will need a leader and therefore a suitably skilled person will need to be identified to lead the activities defined in the mission statement.

The Centre 4 Enablement must support the technical implementation of the MuleSoft AnyPoint Platform and will therefore need a Platform Architect with suitable qualifications to establish, maintain and enhance the platform.

Some organisations may decide to include a strategic consultant as part of the C4E to enable the organisation vision to be aligned with the integration capabilities, while others may include a one or more solution designers to manage API enablement, or even business analysts or architects depending on the aim of the organisation.

Governance, I would suggest, will be a major concern for the Centre 4 Enablement and therefore roles around governance of the API designs and the API code will be required. These roles should be supported by automation tools. Wherever possible you should look to reduce the manual effort required to review API code especially where that code need to meet technical, operational and security standards.

Leaving the subject of the Centre 4 Enablement, there will, of course be the requirement to build central, devolved or federated API development teams which will require specific technical and business skills. I would suggest that this would break down into a number of areas.

The development of all API’s must be generated from a business demand, the requirement to build the ‘data plumbing’ connecting one to many systems. We therefore need to start with Business Analysts or, if you are operating in an Agile environment, Product Owners. There is a particular set of skills required to be a good Business Analyst/Product Owner and this should be partnered with at least a basic understanding of integration requirements. MuleSoft certifications may not be required but an understanding would be of benefit. The focus must be on what the business needs in terms of the data required to meet the desired business functionality.

Business Analysts/Product Owners must hand off their requirements to an API Integration Architect in order for the requirements to be structured into an efficient API with the End Points required to support the desired business functionality. This is a very specialised skill and will require a MuleSoft Certified Integration Architect to translate the requirements into a design which can be implemented by a team of developers and, not forgetting, testers who need to ensure quality is maintained throughout the development and release lifecycle.

MuleSoft API developers will be required to have MuleSoft certifications and specialised skills in all aspects of API development. They will work in association with the Business Analyst, for clarification of requirements if required and the Integration Architect for any design queries.

Testing is a very important aspect of all development and it is vital that the testers work with the Business Analysts/Product Owners to develop test based on the user requirements. Testing, wherever possible, should be automated both to allow testing to be performed as the API’s are developed but also to facilitate regression testing during future enhancements of the API’s. Testers will, of course, need to work with the developers to fix any bugs that are identified during testing.

I have mentioned at various points above the need to automate as much of the development and testing as possible in order to maintain an improved pace of delivery. In order to do this a standard set of tools will be required and hence a DevOps, or even better, a DevSecOps capability will need to be established lead by a DevOps Engineer. Whilst not specifically required to have MuleSoft skills the DevOps Engineer will need to be intimately familiar with the DevOps pipeline and all of the tools that form that pipeline. They will ‘grease the pipes’ of the pipeline allowing the users of the DevOps tools to perform their work without the worry of looking after the pipeline as well.

There are three other areas worthy of mention and which play vital roles in having an excellent API development factory.

I mentioned above three options for the implementation of the AnyPoint Platform in an organisation, in summary these were fully Cloud based, Hybrid, and Private Cloud. Whichever you chose you will need an Engineer, for want of a better term, to manage the environment on a day-to-day basis. While the Platform Architect can define the architecture and development of the platform the Platform Engineer will need to perform the maintenance of the platform and work with the development team to ensure the successful delivery of the API’s into the development, test and, eventually, the production environments.

Now, we need to remember that all API’s rely on data sources and data targets and these target data stores, in any organisation, will be tightly protected from any threats which may disclose or corrupt the data originating from an accidental or malicious act. However, the API’s being bult will require secure access to these data stores in order for the API’s to transmit or receive data as required by the business. In order to do this we will need a Network Operations Engineer, NetOps, who understands networking and security principles so that the appropriate firewalls can be opened securely and appropriate networking is in place to support the API development.

Last, but not least as they always say, we have to consider the support of API’s and therefore we require a support function which is operated by one or more Support Engineers. The Support Engineer will monitor the API’s and the platform looking for any issues or failures that may require their attention. Logging, auditing and monitoring of the platform should be built into the system in order that events are proactively alerted to the Support Engineer rather than them having to go and look for events. This will be a skilled job with MuleSoft certifications required in order to interpret issues and triage them to the person who can rectify the problem if the problem cannot be rectified by the Support Engineer on their own.

And so, I come to the operational side of the API capability. The effort required here to operate an API development platform should not be underestimated. Although technical knowledge is not required to perform this role the ability to understand a technical capability, manage the myriad of different skills and different people some who may be working locally and some remotely, and to manage the funding and reporting is a special skill in itself.

The technical teams, as I have described above, cannot operate effectively if they are not supported by the Operational Lead. Some may say that this is project management but its really not. Project Management is certainly part of it but operational management requires the additional skills to ensure the smooth running of the API development capability on a day to day basis rather than a project which should have a defined end date or target.

The answer to the question that I asked at the start of this blog is, I think, embedded in the question of why you decided to implement MuleSoft in your business and where to you want to go to in business terms of your desired outcomes. The guiding path is given in the MuleSoft Catalyst but you need to use this with the knowledge of your organisation and the experience of working in the current business environment. Some things may be possible, others not so but blockers should always be challenged with business reasoning in place and most importantly the long-term vision as your goal.

If required you can always employ a guide for your journey either in terms of someone who has gone through the journey before or through MuleSoft Professional Services who will provide a Catalyst expert to assist you through the methodology. Whichever way you go it will be an exciting and hopefully rewarding journey.