Making the Cloud, Microservices, and Enterprise IT work!

Cloud Computing is clearly well into the hype cycle. Never being one to miss some good hype, I've been paying attention to advise my clients on whether and when to pay attention to this rising option. One of the big factors in consideration is my current location... I'm working outside the U.S. My local country is heavily wired, offers high speed broadband (2-10mbit) to 100% of the country, 50mbit home connectivity in the major cities (100mbit next year), and even offers cell based mobile internet connectivity at 2mbit or 3mbit (competing companies). Company and office connectivity is typically equal or better. The in-country data centers and backbones between them are very high speed. Ping times from in-country web sites typically run 30ms across the various data centers, backbones and ISP's / hosting sites. All in all, compared to the US that's seriously high speed. Yet, all of that is in-country. The one area where the local internet infrastructure is weak is t

When Anne Thomas Manes (of the Burton Group) famously declared in January of 2009 that "SOA is dead", everyone rushed around to understand what she meant. Being that a year later she's still giving presentations on SOA Governance and other SOA topics, clearly she didn't mean that SOA was a failed technology. (There are plenty of IT technologies that come along with much hype but never quite translate into practical usage patterns or benefits for Enterprise IT, and therefore fade away as quickly as they arrived.) Today when I'm talking with IT organizations the majority are doing some level of SOA. So clearly SOA has moved along the adoption curve. The innovators struggled with it but got and touted their early advantage. The early adopters picked it up and integrated it into their enterprise IT model. We're clearly past even the early majority and a good way into the late majority. The late majority are organizations that 2 years ago weren't consider

Every IT system has an internal data and object model. This model is matched with a relational model that turns into the supporting database. When systems interface, bridging the data & object model from one system to another is a significant effort. Signifcant effort means up to 50% of the integration effort! The historical method is for the exposing system to slightly simplify and expose it’s model, and the receiving system to create significant manual code to transform from the exposed model to it’s internal model. Over the past ten years or so, a large number of industry IT consortiums have been working to create industry data+transaction standards. These standards are designed to be highly interoperable, covering each business process and data objects for the particular industry. They appear rather complex (they are rather complex) as they’re designed to cover all aspects of an industry object with necessary flexibility. However, literally years of thought have gone into co

Twitter, in and of itself, is pretty stupid. Or to be a bit more analytical and precise, as a web version of a cell phone Short Message Service (aka SMS), it's incredibly limited functionality provides little room for practical value. (It actually started as a way to reflect a message from one cell phone out to a group of friends on their cell phones, via a web based facility.) By itself, Twitter is a very limited tool that would be permanently consigned to a narrow audience as a small utility function. You can easily think of 5-10 such services that you've tried and (probably) discarded, a few of which you keep using for their narrow purpose. So what differentiates Twitter from hundreds of other narrow utilities that came (and mostly went)? In a word, a Service Oriented Interface. Twitter started from day 1 exposing a simple straightforward Web Service interface. Even further, they never offered a feature without simultaneously exposing it. In other words, there is a Twi