Making the Cloud, Microservices, and Enterprise IT work!

Loriane Lawson over at IT Business Edge has a penchant for touching upon particularly interesting integration problems.  This week she asks … It's interesting: Writing custom code for data integration is nearly universally frowned upon by experts – and yet, I'm seeing a lot of discussion about creating your own metadata solutions for support with integration. My question is: If you're getting away from hand-coding, why would you want to delve into customized metadata solutions? The article focuses upon some of the technical issues and technical approach to such a discussion.  I’d like to focus on the business issues, and how those should be directing the technical approach (but aren’t). Every application involved in integration brings along it’s database (or general data) model and it’s internal data object model.  These models were developed to meet the functional goals of the particular application.  For example, the “customer” representation in t...

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...

A physician and medical informatics specialist brings forward the belief that standard IT techniques, as applied to Healthcare Information Systems, Problems created by lack of scientific rigor in a cross disciplinary, exploratory field such as HIT, which should be guided by the most rigorous scientific principles, are increasing in scope and severity. In fact, I believe medicine is suffering an unhelpful “cross occupational invasion” by the IT industry, with the IT industry’s best interests as the primary driver, not medicine’s... Ominously, there is a lot of advantage to be had with terabytes of uncontrolled data and a political agenda. I fear that what may come from CER that draws upon uncontrolled Electronic Health Record data will be politics masquerading as science. Under such conditions, private practitioners, medical innovators, the pharmaceutical industry, and patients are all in jeopardy. The Syndrome of Inappropriate Overconfidence in Computing: An Invasion of Medicine by the...