In my previous two posts, we started a journey towards providing a fully working, enterprise ready commercial integration platform. At the moment, we are at the point where you have designed your basic functionalities and chosen the hosting method of your platform. After these steps you should have your first versions ready for your customer pilots.
In your first pilot (or pilots) you will find out how your platform works – or doesn’t. You will have your first real-life feedback from customers. You will start to understand how your software fits your customers’ business requirements. You can, for the first time, see your creation in real action.
These are interesting times. Before you can really say that your first customers are production-ready, you will be doing much iteration – in both the platform development itself, and of course in the integration solution parameterized on the top of your platform. You may find yourself in a very quick iteration cycle, essentially pushing your platform from prototype stage into a real production-ready product. Be aware – you should select your first pilot customer(s) very carefully, as during this hectic time you may be tempted to do such design selections that may look very good in the pilot, but may turn out to be a hinder or even a blocker for some later design decisions.
Then one happy day you will find your first pilot customers being moved to production. But be careful. You may have unleashed a beast, and if you are not well prepared, you may find yourself with your hands tied behind your back and feet nailed to the floor.
The reason is because after you have carried your first customer pilots into end, your platform has reached a new stage in its lifecycle. Now it is a living and breathing creature, serving your customers’ business-critical integration needs, and your customer is relying on you providing these services from the present to eternity. Your freedom of choice in creating all fancy new stuff has suddenly significantly decreased. You cannot go and change the basic functionalities of your platform anymore in the way you had been doing all the time in the initial development phase.
Your platform has become a foundation for bigger things. Just like the foundations on top of which skyscrapers are built, you cannot change it any way you like anymore. You have to maintain it, but it will be incredibly hard to replace it.
Still, you can extend these foundations so that new, higher, better, and more beautiful buildings can be built on top of your platform. Essentially, you should now slowly turn your mindset from changing into extending your platform’s behavior.
Fortunately, we humans are good in extending the behavior of existing things. One example is how we treat natural languages like English. Languages are living and evolving entities, and we are inventing new words and ways of saying things all the time. But at the very same time, we have been able to keep the language backward compatible; we understand, fairly well, text that was written hundreds of years ago. After you have entered the production stage of your integration platform, this is now the way to go for the rest of the life of your software.
Let’s take another example more aligned with our topic – evolution of programming languages. There is a huge number of different general-purpose languages in the world – starting from Fortran and Cobol, through C, C++, into Java and C# to mention just a few. These languages have also started from somewhere, providing the basic functionalities, and evolved over time.
For instance, C# was introduced in early 2002 and has gained the position of the primary programming language when building .NET solutions. It is quite impossible to estimate how many developers are using the language, but according to even most cautious estimates there are more than 5 million people using C# on a daily basis. At the same time, the language has reached the version 6.0 with the next version being in the design. And these more than five million people are willing to start utilizing the next version of the programming language, when it is available, without having to rewrite everything they have already done. The language is a great example of a platform that needs (at least to great extent) to be backward compatible.
Because you are not designing a general-purpose programming language but an integration platform that is designed for far more limited use scenarios, your platform most probably will never reach the number of solution developers comparable to the likes of C, C++, Java or C#. However, integration solution developers building solutions on top of your platform are assured that even though you will be introducing new features and capabilities, the older, existing solutions will still work like a charm.
So, what does it mean to extend your platform? Most likely you will be encountering some of the following scenarios in the next months and years:
1. Your customer is willing to integrate an application using and interface or API that your platform does not currently support.
2. Integration developers using your platform are frustrated with some specific way of developing integration solutions and are demanding changes in your design platform.
3. You, your partners or your customers are constantly utilizing the platform in a specific manner, using a design pattern that you just didn’t think of when originally creating the platform.
4. There are technical changes in the underlying components such as the operating system, databases, messaging, or other building blocks that you have used in the development of your platform.
5. You are experiencing constant growth in your customer base and need to ensure that your platform (if you are providing your integration as a cloud service) manages the growth.
The integration interface part is probably the easiest one, if you have followed the tradition of interfaces being encapsulated into connectors or adapters; these should be separate software modules that could easily be added to your infrastructure.
The ways that your integration solution developers work when building on top of the platform may be trickier, but something that you need to take very seriously. When new ways to use the development environment, or new ways to implement specific patterns are designed, you need to take care of the backward compatibility issue. With clever extensions to your development environment you can end up developing seemingly simple additions that may be the best thing to your developer since the sliced bread; a good example from C# evolution is the introduction of null-conditional operators in version 6.0; introducing a new way to write code that every developer is constantly writing, but with much shorter, easier and simpler syntax. And it is backward compatible – if you like, you can still do the same things the old way.
And the things regarding the “under-the-hood” technology of your platform – the technical changes in the underlying components are something that you just need to live with; and what comes to ensuring the scalability – well, that’s a good problem to have.
Long story short: After you have entered the production stage, you have to start extending and forget changing. Make it better, don’t break it.
Next time we’ll move forward in time to the point where you have multiple customers in different industries and the utilization of your platform is constantly increasing. At that time, you need to revisit the topic of understanding your client base – and start thinking about the differentiation from the competition.
