SOA what?? Part II

OK, so it's been nearly one yr since I posted Part I...pretty crazy I didn't consider doing a series on the topic. Anyway, here's some further discussion about the concept of Service Oriented Architecture...

First off, traditional web client applications can rarely be generalized as a thin web client. Like MS Silverlight, what you end up with, using a set of solid WCF services to harness the backend is nothing less than a SOA application taht just so happens to front a rich interactive application (RIA) interface. Calling a Silverlight or Flex app a thin client is akin to wearing a McClaren jacket at a tour through the Maranello factory. So, SOA in and of itself is merely teh notion of using an agnostic set of services that perform complex business logic; the front end application merely consumes what's thrown at it.

Consider your fancy new Silverlight app using Entity framework and WCF services throughout...you've got adjacent customers that could surely tie into those services and solve their own sets of business needs. Data Exchanges are merely a consumer of SOA - such an interface (or exchange) can be created through simple WCF web services or through more complex varieties.

Imagine that Contoso Shipping has this new Silverlight application. Consider the various adjacent systems that interact with the shipping provider. The distributor to the cardboard box maker could use a look-see into your organization in order to know when to send more boxes to you. Our cardboard box maker company uses its own sophisticated, local software solution for its work mgmt, and isn't about to create something and get the shipping company to expose its data.. Instead, our shipping company merely partners with the box company. In doing so, a service contract is setup and those wcf services that provide the interfacing needed (likely existing services that already poised doing other work) are directed out through this new web service. The box company has the bulk of the work from here - they need to extend their local solution (system) to consume these services, transform the data structures coming across and do some analysis. The output sends data points to their system, all the while the system of record remains internal to the box company, but the shipping company gets real-time data from the box company about its # of boxes coming, etc, etc. Make sense?

In this context, a service oriented arch exists that can be consumed by other (dozens) of client applications in order to make use of the data constructs. The service provider merely exposes and publishes its web services to get at the data, and its approved partners get access to the data for consumption, etc.

The interesting part is that of the analysis needed up front to properly put business and technical req's together to facilitate a) exposing a usable service for potential or known users, and b) providing the data exchange using a broad enough declaration of services that can be consumed by the masses. The last, most complex part is that of reconciliation - either the servicing party or the client party must be responsible to resolve data issues that can and will exist between the two parties. In my opinion, it's always easiest to put the burden on the client (consumer of the services). But, this depends on your system of record...if the State, let's say, exposes criminal data to the state counties for use, it likely expects that this is the system of record, and all such edits need to exist in this single system. So, as the State body, we can't expect that the counties will update this system in a fire and forget mode. Counties need to resolve conflicts in the data, e.g., you send me this, and it doesn't match my interface schema or conform to its pre-justified rules, it's kicked out, and you fix it...or, you send me a case record, but some pre-requisites fail, we abort the data exchange, and the county must resolve. The state in this context expects that the local agencies get good data into the system. One step further, imagine the local agency being satisfied with its own local system; they merely have a data entry person stuff data into the system of record (the statewide data stores)...if this person puts bad data in, they resolve it. If not, garbage in, garbage out, especially when in a case like this, reporting is so critical.

SOA what?? Part I

Been a while since posting to my blog...whow knows what SOA is? I can tell you that's it's a powerful set of methodologies that serve many benefits. Most obvious is the way in which information can be exposed and avaialble for consumption, consumption far beyond just storing data, but building solutions that integrate with this data sharing concept in the cloud.

Exchanging data, or the concept of the data exchange, is a very cool way of making your data available; in turn, a consumer of this data can do something useful (write an app that uses this data to solve a business imperative, for example) with it or simply be a subscriber of it.

The interesting dilemma for an organization today is not in the creation of such a data exchange - this is the rather simple part of hte equation. We can stand up data exchanges all day long that expose information - albeit, there is a tremendous need for clean data, so the backend must be able to support this or some large data scrubbing effort is probably needed. The difficult part is writing or extending a client solution to consume this data and do something useful with it - the "work". Understanding business processes in that client organization and how this newly exposed information can be used to solve them requires time and money. It's ever apparent that most organizations simply do not have existing records, documentation, goals, and needs well documented to understand where in the current processes these calls to the data exchanges could/should be made in order to solve the business problem. This is where the bulk of the effort and work lies, and this is where a skilled team is needed to consult and help strategize the how/where/when/why's of hooking up to a data exchange. This requires business analysis, domain expertise, data architects, and tight inclusion of those stakeholders exposing the data to the exchange and those stakeholders expecting to utilize this data to do work.

Moreover, think of the complexities involved. We need to determine the granularity of such an exchange - to what degree is a business capability exposed - is it super granular such that the message interface (xml) is very narrow allowing getting minute pieces of that data structure (age, birthdate, last violation, etc) or do we provide an aggregated exchange, but also bloat the size of the message interface. Here, we could establish a capability to Add a Debt Collection. This could involve associating a person, a debt type, a payment type, a debt amount, etc.

Summary for now...a data exchange is a good exmample of the SOA software strategy, but it requires much work during planning of the data to be exchanged, but most importantly, requires tight integration with consumers of such data structures and even more so a deep understanding of how current or future solutions need to be written to successfully consume these exchanges - pushing work out to the cloud, while also utilizing this data to solve business problems.

...so what does SOA really mean? More on that later...still unsure what the acronym stands for? Ok, it means Service Oriented Architecture. Come back for more discussion.