Over the last twelve years, I have been working with enterprise customers and colleagues to leverage the power of services to enable a higher level of agility. During my travels and interactions I came to realize that there are many barriers to agility, only some of which were technical in nature. The best practices have to be followed, the tools have to be used, and different constituents have to communicate. Even with all of this going in your favor, agility is still far from certain. When all is said and done, change is the reason applications, systems, and even organizations are not agile. Whether you are developing software or a building, changing a component after the fact is a painful and expensive, if not prohibitive proposition. Many people have built a house to later lament not putting in a gas stove or a 3rd car garage. Many architects have designed an application based on US customers to later need to support international addresses. We have all faced situations where we would love to get a “do over” so that we could deal with the internal desire or external push for change.
Almost five years ago, I started an initiative that allowed software developers to get a “do over” when providing and consuming SOAP services. This resulted in the recently-abandoned software solution from Microsoft known as the Managed Services Engine. I learned a great deal from designing that solution and working first hand with dozens of customers that were enticed by the opportunity to leverage service virtualization. It allowed them to not only get a do-over, but to allow forward-thinking companies to accommodate change proactively through dynamic versioning, routing, and policy. That solution was designed to address SOA scenarios ranging from the basic to the very advanced that only a handful of enterprise customers would truly appreciate.
In the last couple of years, it has become very apparent that SOAP will not be the de facto standard for intra-application communication. What is also equally apparent is that no communication standard will be any more agile than anything we have tried so far. Some protocols make it easier for certain stakeholders by shifting the problem around, but the fundamental problem still remains: change causes havoc. It doesn’t matter if you are building an enterprise business application, a Facebook app, or an iPad app. The more powerful your app, the more it uses services… and the more it depends on those services.
OpusGrid is the next step in my pursuit to help make software and services inherently more consumable and agile. I am fortunate enough to once again have some great colleagues to help go make this happen. Over the next several weeks we’ll be unveiling some great capabilities and along the way I’ll be sharing my thoughts on how our journey as well as how the industry is reacting to the ongoing cycle of consolidation and decentralization. Its going to be a fast-paced ride but its also going to be a lot of fun!