A Shot in the Arm - Jason Burke on Health and Life Sciences

Drew, how long have you been at SAS and how did you get here?

[Drew] I've been at SAS for 13 ½ years.  Prior to working at SAS, I worked for a company that was a reseller of an enterprise content management system.  In that role, I developed solutions for managing architectural, product, and engineering drawings and ancillary documentation.  I joined SAS bringing this experience to the then-budding SAS solutions focused on the pharmaceutical industry.

You have been working a lot in areas related to common software services over the past couple of years.  What is the objective behind these services?

[Drew] There are quite a few benefits to be gained with a service-oriented architecture, in general.  From a solution provider's/developer's perspective, SOA does wonders for enabling, and in many cases enforcing, several fundamental software engineering best-practices – modularization, separation of concerns (decoupling), encapsulation, reuse, etc.  Those are the fancy terms that result in very desirable traits, such as: easier/quicker to enhance functionality and performance;  easier/quicker/more accurately test, fix, and maintain; easier/quicker cross-product integration; easier scalability; etc.

Specifically, this effort is somewhat of a re-factoring across all of the SAS solutions.  We are moving functionality that is common across all of the solutions into a set of platform services.  Not only does this offer the benefits I mentioned above, it frees the solution developers to focus on the features and differentiators specific to their solutions.

How do common service standards differ from other standards like CDISC and BRIDG, and what do they provide?

[Drew] In short, one is used for application consumption and integration and the other is used for data consumption and integration.

CDISC and BRIDG are data standards/models/specifications that define the contract(s), or rules of engagement, between the producers of some data and the consumers of that data.  Without these standards, consumers (the technologies that make sense of these data) have to deal with different contracts for each provider.  Try to combine or simultaneously analyze data from different providers and the problem is that much worse.  These standards decouple the consumers from the idiosyncrasies of each of potentially thousands of providers.  All providers conform to a standard model/contract and the consumers only have to deal with that one contract.  Combinations are a non-issue – it's just more of the same.  This concept is very powerful.

You might have recognized that I've not differentiated data standards from the services description above.  In fact, decoupling is a shared goal of these two types of standards.  However, if you consider data standards are a common way to describe the "what," then services standards are a common way to describe the "how."  That's the difference.  Service standards define the contract(s) between business operations and the consumers of those operations.  This decouples the consumer from implementation details of the provider.  As long as the contract is upheld, the provider is free to choose the implementation that best meets the efficiency, robustness, scalability, persistence and deployment requirements.  Likewise, new and varied end-user applications can be built consuming the service(s) in new ways without impacting the service implementations.

For a long time, application integration was done via data models.  Application A stored its data and metadata in some persisted structure.  The definition of that structure was exposed and Application B could consume it.  However, as the software industry has matured (no, really, it has) we learned there are too many shortcomings to this approach.  First, by enabling access to application A's internal structure, we bypass all business logic that application A might want to enforce.  For example, application A might keep track of the number of times a particular value is read.  If access to that value is given without going through application A, the value may be read many times without being recorded by A.  Also, once application A exposes the internal structure, it's now bound to always use that structure.  Even if new and better methods/techniques are invented that will improve application A's performance or add functionality, it can't break the contract – application B stops working.  The SOA approach fixes these problems.  By abstracting functionality into discrete services and exposing those services, applications are free to hide how they do things from the consumers and consumers are always going through the business logic of the provider. I believe one of the big challenges we face is getting our developers to know when/where data models apply and when/where service layers are necessary.

How would a customer be able to use these services?

[Drew] Our architectural strategy supports a variety of consumption technologies.  There's a lot of buzz (hype) around SOAP/XML Web Services.  We will support these types of service contracts where they make sense.  However, for consumers/integrations that support Java, a far more efficient and friendlier native API will also be available.  Additionally, more efficient and friendlier native APIs enabling the consumption of the services from Flex clients will be available.

Initially, we may choose to expose or publish a very limited set of services.  Once we publish a service contract, we are agreeing to maintain it for a very long time.  It's better for everyone to only publish thoroughly vetted service contracts.

What industry solutions do you expect to take advantage of this common services model?

[Drew] Eventually, I expect all solutions across all industries will consume at least one or more of the core services.  I believe the increasing interest in software as a service deployments, in the HLS industry in particular, will drive the consumption even more.

Do you read blogs, and if so, which ones?  What other sources of information and social media do you use regularly?

The handful of blogs I read are mostly for entertainment – politics, comics, music, etc.  I subscribe to a number of feeds for my technical information – InfoQ, Slashdot, Google Tech news, JavaLobby, Java Tech Headlines, Adobe Flex Dev Center, etc.

I have accounts on Facebook, MySpace, Twitter, LinkedIn, etc.  However, I'm not an active member on any of them.  Following me is easy.  I'm either on the computer, with my family, riding my bike, or listening to/playing music.  Or any combination thereof…