Are IT Techniques Hurting Medical Care?

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 Information Technology Industry? Read the whole thing.

Service Oriented Architecture vs Service Oriented Integration

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 the Customer Management System to perform the task. However, if the company decides they wish to add the ability for customers to self-change their addresses in the Customer Website, exposing the change of address function of the Customer Management System for access by (integration into) the Customer Website is the way to go.

This is Service Oriented Integration - a subset and building block to SOA, Service Oriented Architecture.

When we begin to model new applications (or major functionality changes to existing applications) as granular business services with standardized interfaces, combined together to present a larger group of business operations, then the IT systems have entered the realm of true Service Oriented Architecture.

Service Oriented Integration:

- Targets “Integration Spaghetti”
- Moves integration logic out of the applications into the central integration space.
- Creates integration reuse.
- Allows for composite functionality – composite services.

Service Oriented Architecture aka Enterprise SOA:

- Changes the Application Design Pattern
- Targets Narrow Business Functions with matching IT System Functions
- Decomposes traditional systems into their business processes.

Service Oriented Integration often starts with developers grabbing the latest tools to ease integration. When it becomes an enterprise effort it moves to ‘just a better middleware’. With maturity and proper management it moves onward to an improved integration pattern.

Service Oriented Architecture aka Enterprise SOA presents a new application design pattern focused on creating service components which are effectively (either by manual coding or by tools such as BPM and Portal tools) assembled into applications. By extension it creates a new business to IT interaction pattern, as IT starts talking to the business about granular business process functionality rather than about departmental functionality.

Later, as the business reorganizes business functions, IT gains a similar capability to reorganize the IT ‘systems’ via the assembled service components.

This is the end state goal of Generation 1 SOA. Generation 2 SOA virtualizes the the component deployment environments (the Cloud) and fully utilitizes underlying supporting IT or even business functionality. A very logical repositioning of Generation 1 SOA goals against the evolving state of IT resources.

Glueing Applications Together

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 realizing these future benefits even today?

The surprising answer is, unfortunately a technology set not frequently found in the corporate IT setting... LAMP. Linux - Apache - PHP - Web 2.0 technologies.

Many social media web sites, news & media websites, blog utility and other similar functionality websites are following this model today. Such sites are uses services between sites, loading modules between sites, using cloud services (such as Amazon S3 storage services and EC2 cloud computing services) today.

Many sites have built major portions of their business models based on the use of services, components, cross-site interactions and cloud (or cloud-like) capabilities.

They may be the only businesses practically using the future model today. In a future article I'll discuss some practical examples.

Mainframe SOA - Part 1

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 variable length data elements, optional data elements, and much data structure depth.

- CICS added a pretty straightforward easy way to expose a web service and have it activate a COBOL subroutine on entry (as well as processing the SOAP header). However, IBM reports that under load this CICS facility may perform poorly or require excessive CICS environment resources. (I've never had a chance to see actual results under stress testing.)

To be continued in Part 2, Third Party Tools Covering These Gaps.

SOA as Centralized Integration Control / Management

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 itself, Service Oriented Architecture, but a sub-component of the SOA model. It is misrepresented by many a vendor as SOA, and many a vendor Integration tool is labeled today as SOA. Such tools can be a step towards SOA, but usually are just sophisticated integration tools. Nice, but incomplete.

Illustration courtesy of Zapthink from "SOA and the Zachman Enterprise Model".