BizTalk in our SOA

Below is an example of BizTalk in our environment. It depicts a real use case required by our business team.

The System of Record for Mary Kay Item data is our ERP application (J.D. Edwards Enterprise One). This has been declared by the business team of two organizations within the company (gasp!). Anyone who would like to subscribe to Item life cycle events should be able to register as a listener and receive them (BizTalk Messaging). All Supply Chain applications (5 domestic and 2 international) receive these life cycle events.

Of course, chances are if you give another application an Item (or a cookie), its not going to know what to do with it. Using BizTalk Transformations we normalize the Item event generated by JDE into a Mary Kay Supply Chain Item (working on further normalizing into just Item, old habits are hard to break). This SCS Item is now what everyone subscribes to. In the event that the System of Record becomes another system, or the schema produced by the current System of Record changes, the source schema can still be transformed into the SCS Item, thereby protecting subscribers from change with this layer of abstraction.

Once you start getting multiple applications talking together your probably going to need to add more than rudimentary business process. e.g. add an itinerary to process. e g. step 1, then step 2, unless some condition, then do step 3? BizTalk Orchestrations will allow you to handle this type of process flow.

While your implementing your business process, your likely to need to leverage a business rules engine. Something that's dynamic and can be updated at a moments notice in the event the business needs changes. Well, then the Business Rules Engine is your friend.

Gosh, now that I've got all this data flowing back and forth between my applications and systems, your going to need to track the data (Health and Activity Tracking). Things invariably go south at some time or another. Where is the message when this happens? Once you start tracking data your going to want to identify and track key performance indicators. Why did it go south? How long did it take the message to get from point A to point Z including all steps in between? This is where Business Activity Monitoring will help out.

Anyway, enough of a commercial for BizTalk. Don't know why my train of thought carried me down this path, but it did.


Footnotes
[1] Instead of 'normalization' I used to use the term 'canonical', meaning the generally accepted standard for the item. This term did not convey the right associated response they way that 'normalize' seems to.

SOA Customer Roundtable Followup

Had the opportunity to participate in a Q&A session with other Microsoft customers regarding our approach to Service Oriented Architecture. Overall, the session was geared to be very high-level (CIO, CTO) and it definitely was...almost nose-bleed level and I certainly didn't do much of anything to bring it closer to Earth!

If we are one of the furthest along in SOA adoption, then it might say something about how well SOA is understood, or how much value it provides. There were many slides by both SOA Institute and Microsoft that brought back sharp, painful memories of the COM era....implementation indifference, location transparency, loose coupling...it was like a 10 year class reunion on buzzwords!

All that aside, there are many elements of SOA (or COM, or -[insert here]-) that are worth considering; we've still got a good way to in maturing how we approach our goals. For instance, writing well defined services is not enough. If these services (and related assets ) aren't discoverable, via some common registry, then no one will use it and we still have a continuous drain on the organizations ROI.

Once these services are discoverable there needs to be governance on the service life cycle. Who is using it? How are they using it? Should there be a usury fee for the service? Is the service meeting its stated SLA for a customer? What do we do if its not? These are all types of scenarios that we need to be evaluating our need for.

We are off to a great start, but we need to start thinking about more of a long term investment vs. the quick fix that our initial approach gained us.