Technology and Strategy for Web Scale Services by Dan Hushon

Main menu

Tag Archives: Service Oriented Architecture

RSNA was an exceedingly interesting show this year, the concept of a framework for integration based upon a Service Oriented Architecture (SOA). More interest in meaningful use and the cross-integration of clinical platforms. I feel like we’re on the verge of a substantial trend toward integration for both the delivery of care as well as institutional operational enhancements.

Tom Maguire pointed me to an interesting podcast from Marty Moseley, CTO of Initiate Systems, one of 2 remaining leadership quadrant companies in CDI & MDM (the other being Siperian). Marty wanes relatively eloquently on this “third pass” at MDM, and the challenges that MDM faces/addresses within a SOA/BPM oriented set of orchestrated activities.

So there has been much ado from commercial technologists, analysts and press about the emergence of SOA as a silver bullet in the defining of a common Enterprise / Inter-Enterprise Service model, and in an approach to the re-factoring of existing legacy systems. Though there are almost as many approaches to SOA as there are articles defining and re-defining the terms, one of the critical lessons is that SOA will only yield as much agility as the infrastructure upon which it runs.

Coming from a history of grid/utility computing programs has afforded me the benefit of viewing enterprise resources as consistent model-able elements that can create a virtual deployment infrastructure for this next generation of agile enterprise services. What remains critical, and a common theme in my weblog has been the need to better elaborate the systemic requirements of a system – whether represented by a single service interface, or through a composite model, service level objectives remain a difficult to define, more difficult to measure, and virtually impossible to predictably enforce set of goals. A recent read of the Enterprise Grid Alliances “Reference Model” is illuminating; as I think that the industry, through GGF, EGA, DTMF UCWG, SNIA and even eTOM are getting close to a basic taxonomy in which a SOA is deployed (hopefully dynamically) against a Service Oriented Infrastructure (SOI). So what am I really saying? Model Driven Architecture is attempting to establish consistent patterns for the organization of object oriented services, with clear separation of concern, and appropriate compositional granularity. SOA’s are constructed through Directed Acyclic Graphs of these sub-systems that define their inter-relationship (though the complete vocabulary isn’t standardized). Now that we understand the components that make up an enterprise service, we need to determine how to apply these models against infrastructure, and once again MDA can serve us well.

Let’s take our infrastructure (pools of elemental resources) that can also be dynamically assigned, are themselves objects, which can leverage similar model based approaches to their organization we quickly begin to recognize the need for both “extension” – supporting a consistent interface to a domain model, whilst enabling the customization that is a natural byproduct of real-life variability. Models, for me are a composition of patterns that provide layered abstraction to mitigate complexity and support replacement… These models are really purpose built realizations of patterns based upon a set of concrete contexts – a complicated way describing constraint driven pattern application…. I want to remodel my bathroom, to build a plan I need to take existing patterns from some kind of “standard” catalog, and apply them given my constrains… I’m tall, so I want the countertops raised, I’m disabled so I need to extend the natural 18“ on center rule for toilet spacing to 36” for access… you get the picture. By producing models (either abstract or concrete) we can begin to elaborate a design, manifesting all of the complexity within a set of stackable “layers” that ensures both loose coupling/east of replacement, along with the traceability against requirements and constraints.

So finally to VOA or “Virtualization Oriented Architectures”; architectures built with clear layer based / atomically separable abstractions… VOAs are Models in which abstraction can be late bound, but coherently orchestrable designs. These designs need to describe the “virtualization” constraints in a way that deployment contexts can be manifest at runtime rather than design time, through a more consistent set of abstraction layers/patterns that reflect the platform layer, service layer that you wish to virtualize. In lay terms… virtualization provides a component and a container that inherently provides the lifecycle management of that component. For VOA to work (as SOA) the functional capabilities as well as the non-functional or systemic capabilities need to be declared at design time, and then contractually provided at runtime.

I have long said that the failure of SOA programs has to do more with politics of data/process ownership than the technologies on which you build these enterprise SOA initiatives. Furthermore, that the failure to address the information models as first class citizens in a Service Oriented Architecture presents huge risks to both adoption and down stream architectural stability.

As background, working for an Information Infrastructure company, and having worked from a “computer company” in the past, the realization is startling wrt. how easy it is to “re platform” and application (note Sun’s precipitous decline in the face of Linux) vs. re-platform it’s data… after all: Computers are worthless if they have no data to process. And to further this point, as processors got faster, at a rate much higher than the busses that fed them, they became more like space heaters. On the other hand, the information supply chain has grown in relevance as technologies like de-duplication, parallel readers, advanced caching algorythms and even flash disks prove to have a more substantial impact on timeliness of result and thus architectural criticality.

So what does that background have to do with our story? Well all businesses are being told to do more with less; investments are being targeted to deliver real ROI as measured in Revenue, and to some extent, though SOA enabled processes support the automation of processing paths, the programs that I have seen fall short in that traditional SOA offers enterprises the OO promise of a singular Service (first class) which is responsible for Employees, Customers, Accounting, the business unit functions, and this falls short when you ask the simple question… but really who owns the “Customer”… Okay so now everyone raises their hand… the problem now becomes one not of a singular service, but the federation of capabilities across systems exposed through a consistent interface… all well and good until you ask: what is the information model upon which these interactions act. Again, the political fight ensues as to who has the best model, to which there is no answer except the one “whomever has the money makes the rules”… okay so sales wins. No really, SOA needs to become substantially more grounded in information modeling and Model transformational techniques with the recognition that there will never be a single canonical model for the business. But, how do we navigate across these models? EIM(MDM)/EII(MDM) techniques of course? But as we build these transforms to move from model A to model B potentially through some canonical intermediate, we need to concern our self with the impact of changes models included within the orchestration… enter model governance. Yes, the G-word. Governance seems to be the impossible cross-matrixing of staff to produce some semblance of order within a process in which politics, unknowns and of course expectations wreak havoc on the scientific method. One of the critical expectations which needs to be continually addressed is timely-ROI, you have but 6 months to demonstrated tangible evidence of success or you risk losing support… now back to the software development/SOA domain.

eSOA programs have long put waterfall methodologies out of vogue because they seemed to lack “pace and progress” to this end tight spiral RUP based methodologies and even the Agile methods have come into vogue. Learning from that, there is an opportunity for Information Architects to emerge that don’t boil the ocean, but do through an iterative and constructive process continually refine the models, transforms, interactions, accessory/usage policies, stewarding mechanisms that are required to improve consistency (think SEI/CMM scale). Sure, it’s a never ending journey, but at least you don’t get too far away from the business to be viewed as a field of dreams (inconsequential). To this end “Agile Data Governance” is coming into vogue, alongside the realization that SOA, like IT is about the information, and forgetting that we are doomed to follow in the footsteps of failed efforts.

I was recently asked to contribute to a couple of articles(The Merging of SOA and Web 2.0,Experts See Link Between Virtualization, SOA) by Darryl Taft of eWeek(Ziff Davis). I initially took an excessively “SOI” approach to this discussion only to have a conversation with Steve Graham that really helped me establish a more realistic set of comments around the junction between Web2.0 (with it’s requisite behavioral challenges around collaboration, composition and empowerment/personalization), and my natural slant toward SOA – namely the changing dynamics of system composition with a strong bent toward “systemness” or NFR’s.
The quote is certainly more accurately attributed to sgg, but is certainly a collaboration!
Thanks Steve!

Given some of the comments on my last post on "Why Agile, Lean and Six Sigma must die" ... I thought I'd take some time to clear up another misunderstanding in the difference between position, flow and movement.Let us assume you've examined a line of business, starting from the point of user needs and developed […]

Every large system (whether a line of business or specific IT project) contains multiple components. Those components have a relationship with each other (known as position) but they're also evolving. Every components start as something novel and poorly understood - the uncharted space of the new e.g. the first telephone - and over time through demand […]

Simon Wardley

Login

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by CSC and does not necessarily reflect the views and opinions of CSC nor does it constitute any official communication of CSC.