In September 2016, I attended the 11th iCMG architecture world summit in Bangalore. This sponsor free, vendor neutral event brought together an array of professionals from more than twenty countries from every continent to share about their experiences in applying the discipline of enterprise architecture within their respective enterprises or consultancies. Two case studies stood out during the event. In the breakout sessions, I listened to a presentation by Localiza Car Rental from Brazil that demonstrated how they used the concept of microservices to improve business agility in service delivery. I also listened to a presentation by AKBANK of Turkey on how digital and API banking supported by SOA vision using a concept of multi-channel architecture.
There were tonnes of other breakout presentations which I wasn’t able to attend due to time constraints. However, each of the presenters shared a common theme – thought. A lot of thought had gone into the design and implementation of whatever solution (suggested or realized) for the respective business problem. The diversity of approaches to solving the respective problems was balanced by the convergence of why the problems were being solved. Each of the presentations linked back the method and outputs to how different the enterprise was or is expected to be as a result of application of the solution(s) developed. The thinking in each case was top drawer.
In his opening remarks, Sunil Dutt Jha CEO of iCMG, stressed the importance of having the right people to whom the CEO can explain his or her problems to. In his presentation, I recall the words, “technology is not changing, the implementation of technology is”. Those words stuck in my head. The words at face value then appeared to be rather confusing. However, after ruminating over them for months, I have attempted to piece a meaning out of them.
In doing so, I read a piece about the differences between SOA and Microservices from a couple of experts in the trade. This would somewhat mirror the case studies of Localiza and AKBANK in the summit I attended back in September. One such expert is Matt McLarty, a software architect who leads API Academy at CA Technologies. He is also a co-author of the book “Microservice Architecture” from O’Reilly Media. In his article, he describes what lessons can be learnt from the rise and fall of SOA in order to best use microservices. One of his bullet points talks about focusing on what is lasting rather than what is transient. He says, that patterns and principles last but technology doesn’t. In his assessment, when technology vendors of middleware convinced the industry that ESB was not a pattern but a product and the subsequent adoption, complexity increased and the original intent of SOA was compromised.
Going back to Sunil’s words, implemented technology is the result of thought and deed. SOA and Microservices begun as thoughts that later on have become realities. Each of the thought attempted to address the same problem using different perspectives albeit with some similar sub-parts. Wikipedia defines technology as “the collection of techniques, skills, methods and processes used in the production of goods or services or in the accomplishment of objectives, such as scientific investigation.” I suppose many have used the term as a noun to refer to the “thing”. This definition points to more of a verb. The latter may have been what Sunil was attempting to communicate in his presentation.
If the “thing” is the technology, then what would we call the thinking and the doing that produces the “thing”? McLarty may have given us a clue by his reference to patterns and principles. In order to produce the “thing”, some pattern must exist or must have been determined. Additionally, how pattern is realized must be guided by something else, that something is principles. It requires some skill to recognize patterns and discipline to follow through principles in applying the techniques, methods and processes required to produce the thing. These terms as defined, mean that the thinking behind the “thing” has an unchanging structure but the execution of thought may use different ways to address the problem, as illustrated by the case studies above.
Solving similar problems
Consider the manufacture of the first brand of a mobile phone compared to the production of a smart phone. These are different products with different features but having a similar problem to solve. The thinking behind the first brand of a mobile phone must have been inspired by the patterns and principles available at that time. The smart phone on the other hand is informed by patterns and principles available today. The difference is time, seasons and preferences. Technology as a verb didn’t change but the implementation of the means to mobile interactions has changed over time.
Our modern day conversations may refer to change of the thing as well as imply changing of the framework within which production of such things is done. If this be the case, then we may be focusing on what is transient and forgetting to look at what is lasting. Given the high rate of technology (the “thing”) obsolescence it would be foolhardy to build a future on the “thing”. Surprisingly, it is not uncommon to see enterprises build their strategy on a technology (“the thing”) rather than technology (“the thinking and doing”).
In conclusion, I will use McLarty words : “Every Docker will have its day, but microservice adopters should embrace the patterns and principles, and prepare for technology obsolescence”. This is true not just for microservices but generally for any technology (“the thing”) movement. We need the “thing” in order to address the problem today, but once the “thing” is no longer able to meet our growing demands and another “thing” takes its place, we must have the ability to see through the pattern and principles implemented by the “thing” and use those as a basis for considering the next “thing”.
That was my deduction of the two presentations I picked for consideration in this post. Nokia 3310 would be the point in time implementation of means to mobile interactions in the late 90s and early 2000s while the smart phone would be the point in time implementation (not means) to mobile interactions in the period after that. The patterns of a keypad, a lens, a speaker and a battery slot among others still define both sets. However, added features (for instance data and storage) increases the principle’s instant messaging. Therefore in my understanding of Sunil’s words, technology is the verb (thoughts, methods, skills and techniques) while its implementation is the noun (the thing).
About the author
Peter Muya, is an award enterprise transformation practitioner, possessing 15 years experience conducting mid and large-scale transformation projects in the telecommunications, financial services and public sector industries. He is the co-founder and a managing partner of PTI Consulting, a pan-African consulting practice providing ICT related business advisory services