Introducing MuleSoft Products to an organisation
What are your strategic challenges?
In his weeks article I want to stray a bit from the MuleSoft Catalyst and address another issue that I have had some queries about and which I think may be a good point for consideration for those implementing, or thinking of implementing, MuleSoft in their organisations. Although the subject is not directly related to the MuleSoft Catalyst it is very relevant to anyone working on the introduction of an integration capability within an organisation. What am I talking about, well, I’m talking about identifying and deciding how to manage other integration capabilities that are already present in the organisation.
So, when you are looking at introducing MuleSoft Integration capabilities into an organisation, as I have said in the past, you must understand the landscape in both business and technology terms into which you will be introducing the capabilities and you must understand them well. Understanding at a business and technology level while important also must be considered in terms of people and their attitude and beliefs. Let me explain in more detail.
The current landscape
Now, I can pretty much guarantee that, unless you are working in a start-up situation or on a ‘green field’ implementation you are going to find that there is some form of data integration already in place within an organisation. Systems very rarely, and shouldn’t, survive on their own. What kind of integration capability may be in place? Well probably one of the following.
Point-to-Point model
At the most basic level, and the one that provides the most challenges to an organisation in terms of support and change control, is the point-to-point interface model. If you find these in place then you are probably on to a winner as any modern integration technology will provide more benefits than the Point-to-Point model. Unfortunately, if this is the only integration technology in place then you will probably find a significant number of these types of interfaces. Problems associated with Point-to-Point interfaces include:
o Changes in one system may require changes in all of the connected systems.
o Change control and version control becomes a nightmare.
o Cost of maintenance is very high.
o Configuration Management becomes very difficult.
Enterprise Service Bus (ESB)
In this model each system has one single interface with other systems and therefore changes within one system do not impact the other systems that it communicates with. By providing a centralised infrastructure for integrating disparate systems, an Enterprise Service Bus simplifies the complexity of enterprise integration, promotes reusability, and enhances agility and flexibility in adapting to changing business requirements. However, there are disadvantages including but not limited to:
o The implementation and maintenance of an ESB can be complex and require specialised skills and expertise to run and enhance.
o An ESB, by the nature that it holds data in a single place obviously becomes a Single Point of Failure and therefore require more support.
o Performance issues with an ESB can propagate across your network hence having a wide impact on the business as a whole.
Service Oriented Architecture (SOA)
The Service-Oriented Architecture (SOA) model is an architectural approach that facilitates the development of software systems by organising functionality into reusable, interoperable services. These services are designed to perform specific tasks or functions and can be accessed and reused across different applications and platforms. This model has been very popular in the past due to its characteristics in providing modularity and providing the ability to reuse services through its flexibility, agility and the ability to scale the services as required. However, it shared a lot of the disadvantages of the ESB model in that it can be complex to implement, it is subject to performance overheads and publication and evangelisation of the services can have its own challenges. In addition though maintaining data consistency and integrity across distributed services can be challenging when using multiple services to perform a business function.
Microservices Architectural Model
The Microservices Architectural Model is, in my opinion, just a variation of the SOA Model where the Services provided are deconstructed into smaller independent services each focused on a specific business capability. The services in this case are designed to be loosely coupled, independently deployable, and scalable, making them easier to develop, maintain, and scale compared to SOA services.
Overall, microservices offer numerous advantages for building and scaling software applications, including increased agility, scalability, resilience, and innovation. However, adopting microservices also introduces challenges such as increased complexity, distributed system management, and operational overhead.
Why does the current technology and staff matter?
It matters a lot and if you don’t take it into account you will find problems further down the line!
Let me look at this from a number of angles and then the problems may become clearer.
Strategy
From a strategic perspective there are a number of decisions that need to be made very early on when planning the implementation of a MuleSoft integration capability into an organisation. The obvious first question is will MuleSoft completely replace the existing integration technology(s)?
If the answer to this question is yes then you immediately need to start thinking about how this will be achieved in a number of areas:
Legacy System Compatibility
Can the new technology support the legacy systems? In some cases you may still have legacy systems running on mainframe platforms, which is certainly a case I have seen, so what do you do about this? Migrate the system or exclude it from the new integration technology? Some older systems may not be suitable for modern integration tools and will therefore need to remain with Point-to-Point interfaces for example. Hopefully these will be few and far between but you should still keep this in mind.
Business Process Alignment
Existing integration technologies are often deeply intertwined with core business processes and workflows. Replacing these technologies may require re-engineering or restructuring existing business processes to align with the new integration capability. This can involve significant organisational change and may encounter resistance from stakeholders. I will discuss this more below.
Skills Gap
Now there can be no doubt that adopting a new integration technology is going to require either training of existing staff, hiring personnel with the necessary skills and expertise to design, implement, and maintain the new platform or a combination or both. The real question here with replacing the current integration technologies is the suitability or willingness of the existing staff to be trained in the new technology. You need to be prepared, at least in theory, for anywhere between reluctance to change right through to the departure of the staff to other organisations using the technology they are familiar with.
Disruption to Business Operations
Replacing existing integration technologies will result in some level of disruption to the existing business processes and operations and therefore any changes need to be carefully planned to mitigate the risk of service interruptions.
Costs, Resources
I think it is clear from the points above that the replacement of the current integration technology(s) will inevitably result in impacts to cost not only those associated with the new technology but also staffing and operational costs. Certainly, with my experience with implementing the MuleSoft AnyPoint Platform I have found that costs will increase with the success of the platform. However, and this is an incredibly important point to make, costs should also take into account the benefits in order to understand the total cost of the implementation. Building reusable products and components is fundamental, in my view, to a successful implementation. Remember reusable components will lead to avoidance of development costs and quicker delivery times for future projects as well as opening new and innovative opportunities for the organisation.
Human Resources (People)
Now this area is one of the most complex areas when introducing new integration technology and, if fact, any new technology. This is especially difficult, as I alluded to above, if the introduction of the new technology is going to remove, not immediately but at some point, the other incumbent technology(s). Having said this what do you do if the current staff are required to perform some activities and are reluctant to embrace and/or retrain into the new technology? Well, I have experience this with a large banking takeover and in a utility merger where staff were asked to perform work and complete projects before they were made redundant. This issue is something that could be the subject of many articles but here I just want to make you aware that this will be a significant consideration when replacing existing integration technologies.
If the answer to the question of whether the new integration technology will completely replace existing integration technologies is no then you have a completely separate set of issues to address including:
The questions for consideration if you are not replacing existing integration technology(s) are generally the same but the outcomes will be completely different but will still require careful consideration and management.
Let’s look at the same category of questions as above.
Legacy System Compatibility
If you are maintaining existing integration technology(s) then the issue of legacy systems goes away. Or does it? The longer legacy systems are maintained the more expensive they can get and therefore the question still remains around costs of not only maintaining the current system but also maintaining the current integrations. In one view this problem may be deferred rather than resolved which could be an even worse outcome.
Business Process Alignment
In the case of business processes the current business processes could remain however the questions then revolve around whether the new integration technology can work with these existing processes and even enhance them or will a completely new set of business processes be required which will sit alongside the existing processes? Will this make business processes more difficult to maintain and increase costs or is this just additional cost for the new processes?
Skills Gap
With this section the gap now is limited to the skills required to design, implement, and maintain the new integration technology. But what if the existing staff want to retrain to use the new technology? Will they feel threatened by its introduction or will they embrace it?
The challenge here may be new technology envy! Beware this because envy may lead to negative feedback to the business for the new technology(s)
Disruption to Business Operations
By adding additional capabilities, in the form of a new integration technology, the challenge is to identify where the new technology should be used and where the ‘old’ integration technology should be maintained. As an example, you may have one area of the business which is of critical importance but is ‘comfortable’ with the existing technology and does not want to move to the new technology. Do you leave them to carry on as they were and never use the new integration technology in this area or do you try and build a migration plan? If there is a requirement to work with the current integration team(s) how will this work? Will each team embrace the other and form a constructive relationship to the benefit of the organisation or will there be a strained relationship? Each organisation will have to find their own answer.
Costs, Resources
The big issue with costs and resources raised by keeping the old and new technology(s) is the, probably, significant costs in maintaining a number of technologies and platforms that in business terms at least provide the same function. One of the questions here would be why are you bringing in the new integration technology when you already have one or more in place? Maintaining numerous technologies and their associated platform and specialised staff is a very expensive option and would need to be clearly justified.
Human Resources (People)
So, if the existing technologies are to remain then no one is made redundant. Happy days! But from an organisational point of view you now have an increased in specialised staff to not only maintain the current Integration technologies but staff the new one. There will inevitably be training costs and recruitments costs in some form whether these be new permanent employees to the organisation or some form of third-party outsourcing. If multiple technologies are remaining costs will inevitably increase.
Summary
In this article I hope I have highlighted some of the key strategic questions that will arise when you are introducing new Integration technology, such as the MuleSoft AnyPoint platform, into an organisation. These are very high-level questions and much more detail is provided in the MuleSoft Catalyst methodology and the Delivery Approaches provided within the Catalyst Knowledge base.
Please always remember that the Catalyst Methodology, whilst based on a large base of experience across many industries and organisations, is still just a methodology and each organisation will have its own unique challenges and ways or working. You need to use the methodology with your own intelligent collateral of your organisation or, if you are a consultant working on an implementation project, you need to invest time in understanding each unique challenge. The most important skill here, as in a lot of cases, is listening and understanding the people that work with the existing technology on a day-to-day basis.
