Making the Cloud, Microservices, and Enterprise IT work!

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

As we've discussed previously, Service Oriented Integration and Service Oriented Architecture are not the same thing. Most organizations have progressed to some level of Service Oriented Integration. (Often this is bottom-up, as the tech teams have just imported the technology as an easier way to get this done. Less frequently it's top-down, where the technology approach has been selected specifically as part of the solution to the business problem presented.) When existing applications are adjusted to expose granular business functionality, we refer to that as exposing “services”. More specifically, exposing business oriented web services – business transactions or small components of business functionality are exposed for use by different applications. Example – The company’s primary Customer Management System contains the customer data. A customer may call the customer service number and request a change of address – with the customer service representative accessing

As I talk about SOA future vision, the 'ultimate state' or end stage goal, I frequently speak of application assembly. Application assembly is a future state goal where services and components are linked / bound / process workflow managed by specialty environments (perhaps ESB's or more likely BPM suites) into 'virtual' applications. 'Virtual' because the components are being orchestrated into the common larger business processes and are not an actual single block of code working tightly together as a single application - the traditional big-box application. After having this conversation at some clients for about 2 years, many are starting to get it and express some of this future state vision as they work with the business on today's goals. And they are taking practical steps today that let them realize limited parts of the vision and/or take some steps towards the future. But the question is, what technologies are in place that actually are realizi

What is Mainframe SOA? For the purposes of this article, I'm referring to exposing web services from COBOL applications in a mainframe environment. (The specific mainframe environment I'll discuss in this article is CICS.) Today there's a variety of tools and native functions that allow expose of CICS transactions or COBOL subroutines (or full applications) as Web Services from the mainframe. In brief, here's what these tools and functions come to solve: - Formerly COBOL did not handle XML natively. - While CICS began to expose web server type functionality some years ago, it did not have any way to link a web request to a COBOL routine. About 3 years ago both of these problems were solved natively, in somewhat of a limited fashion: - Enterprise COBOL integrated XML processing functions into the base language capabilities. However, COBOL is still limited to creating internal data structures using the standard COBOL data blocks. This means it's poor at handling

New generation SOA tools such as ESB’s (Enterprise Service Buses), Governance Tools, and Monitoring & Security tools change the integration approach and model. Instead of point to point connections degenerating into interface spaghetti over time, these tools provide centralized facilities for managing and controlling interfaces and inter-system connectivity. They allow you take control of the integration space, manage & control connections, and provide the potential for connection reuse. They also bridge the technology gaps in many a legacy environment between the interface technologies and methodologies of today and those of the past. Using them allows you to move to Centralized Integration Control and Management. This is extremely valuable to any large IT shop in preventing connectivity chaos and integration spaghetti, as well as significantly simplifying and (critical over time) standardizing interface methodology. This is Service Oriented Integration. It is not, by itsel