Somehow I knew that this was going to be a great weekend.  There's something about spending a wonderful afternoon out on Elliott Bay with the rest of the team that sets the stage for a great weekend.  Thanks Pat (http://www.pathelland.com) for a great time, and the team for great company.  But I think that state of mind set the tone for a great weekend. 

I love the Seattle area, the weather was just beautiful.  I don't think I got out of my pajamas, but that's pretty much the definition of a great weekend.  But the cooler air, the relaxing tone set for the weekend allowed me to experience quite a few of my favorites.

• I got to jump on the trampoline with the kids and I think I wrenched my back.   
• The paint fumes from the newly painted living room, which lookes great, with fantastic looking wainscoting and crown molding that my wife just finished.   
• I did some catching up on reading, software factories, WS-Security and SQL Reporting Services.   
• Played some more Fable late at night, now I own a few homes and am pretty much invincible.   
• Sat today and read quite a bit of The Peloponnesian War by Donald Kagan while listening to Rachmaninov and Chopin, wearing my silk pajamas (this was probably my favorite).   
• Watched my son engineer several new Bionicles (http://www.bionicle.com) from scratch, man is he good at that. 
• Noodled on more elements of a financial architecture, tried to capture some in writing, but that part is not quite ready to come out. 

And so many more perfect moments.  There's something about the Fall that engenders a cathartic melancholy that I wish I could get in a capsule for any time. 

This week has been just crazy.  And today proves to be even busier, but I wanted to make sure that I moved this forward and talked about the supporting PLATFORM tools supporting the Financial Value Chain.  With so many companies espousing web services and service oriented architecture, it's important to note features of base platforms that can be leveraged to extend competitive advantage for a consumer/provider of that service as well as the unique value proposition that Microsoft brings in our tools and platform that compel usage of as many platform features as possible for an integrated experience.

Let's face it, I could duct tape some web servers in front of a mainframe, serialize data in an abstraction layer in and out of that mainframe, expose a few web services in that abstraction layer and call it my service oriented architecture.  And indeed that may be an iterative step and an interoperable one to realizing the full value of the FUTURE of a financial architecture and business application, but it isn't even close to the end game.  With that approach you are still maintaining an inflexible legacy environment and any innovation and flexibility would have to occur in that abstraction layer, sort of defeating the purpose of the "abstraction" layer.  And as anyone knows, a fleet can only travel as fast as the slowest ship, and that mainframe is weighing your architecture down.

This layer of the Financial Value Chain is focused on the platform that runs the service oriented architecture.  It's more than just an operating system and web servers.  Although, the innovation that Microsoft provides as a base part of the OS delivers leagues of value "in the box" over its competitors.  But on top of that is a rich tapestry of servers, runtimes and tools that assist in speeding components of the Financial Value Chain.  And that doesn't even speak to the myriad of operational servers that support that platform like MOM, SMS or the like.  I won't go into depth in this post on a product by product drilldown, but I wanted to throw a couple examples out there. 

There are a couple of elements (not exhaustive) to consider as key in a financial architecture.  Real time transaction capabilities and data access, batch environments, subscription methods and business process workflow.  The first two can easily be facilitated by the SQL Server 2000/2005 environment.  With a database that supports high performance data access (coupled with object and XML serialization) and services like DTS for batch loading and transformation you can accomplish the first two, and where needed can integrate that using BizTalk Server 2004 into a workflow process or use the adapter infrastructure to interoperate with other systems.  Subscription to services is one type of subscription method, but others include subscription to data as a custom request that can be facilitated by SQL Notification Services or other business rules within a database architecture.  In a Financial Architecture some common patterns for these models and how they leverage the Microsoft platform is what this layer is all about.  Plain and simple, SOA is a great concept, but not all features of an application are found in the service bus, many are found in the plumbing level and platform support.  They may extend to the service bus, but they are there nonetheless.  This layer of the Financial Value Chain describes the features or artifacts that EVERY financial application should provide that will speed integration and/or value delivery.

I'll share a historical story in relation to all of this.  I remember when BizTalk Server 2000 shipped and how excited I was.  I saw what it was trying to do, and loved the concept.  Sure, version 1 with the caveats, but the concept and approach was sound.  But I watched even inside Microsoft as technologist after technologist would post inquiries to our internal BizTalk Server newsgroups saying things like "couldn't I just do x, y, or z easier using a C# foo?".  And perhaps that was true for x through z....but what about a through w and all other permutations.  Slowly people bagan to understand that platform servers, like BizTalk, and architecture take common infrastructure and application pain away by making it a platform component standard and add value to it at that level, and allow architects to deliver business value on top of that platform.  That is the layer that is covered in this part of the Financial Value Chain.

...stay tuned for the excitement of Part 5

I'm working up a new "SOA friendly" term for Financial Value Chain (FVC) since that term just sounds a bit overused or ambiguous.  But we'll stick with it for now until I am done.  In this episode I want to talk about two of the layers of the FVC.  Namely I'm going to address what components will be part of the user experience layer as well as those that fall into the category of web services, messaging and integration.  That last category is large so I may be abbreviated here.

User Experience

As I see it, this is the "face" to a service oriented architecture.  Sadly, I feel that as people look at SOA, they see it as a server centric model and all the "services" slant towards those scenarios in which messages are flowing between systems.  Sort of like STP, where everything is a trade settlement or communication between systems.  Well, that trade had to come from somewhere, and somewhere along the way there was probably a human involved.  The sheer volume of users in Financial Services begs a look at ways to make them more productive using common platforms and tools integrated tightly with business solutions.

In the user experience layer I will discuss in depth usage of key Microsoft Office 2003 technology.  One thing that I notice of late is that Office integration tends to be very lightweight, mail merge, document creation and authoring, but not looking at the "document" as an integrated part of the workflow or consumer of the SOA.  So I'll talk about things that every application can do as part of the application to leverage Office.  Those will include producing Smart Tags for commonly recognized elements (like policy numbers or account numbers), using Information Bridge Framework for back office integration and using Smart Documents.  One key element in a workflow is the data entry so I will look at how InfoPath 2003 can be used as a structured data gathering platform and initiator to a server and rules based workflow.  Another overlooked user experience and rich client application is MapPoint 2004 (and related products) which can be used to made educated business decisions based on geography with rich data integration.  And lastly, I'll look a bit at devices.  Probably slanting to the TabletPC more so, as the form factor and ink capabilities really make it compelling in the financial sector.  So I'll discuss common ink patterns and capabilities that every applicable user experience should have.

Web services, Messaging and Integration

This is HUGE.  This is pretty much the core SOA layer supported by the platform discussed in Part 4, and which adds internal application value to the messaging layer.  The first thing to remember is that this is about providing guidance in a toolkit form.  In this process, I will not provide some rigid rules prescribing EXACTLY what to name your web services, but rather, what helps you identify a service that is primed to be a web service and guidelines on how to name it.  I will discuss ways that you should secure your web services and the pieces of the web services architecture that are needed for the application.  This will provide as close to a financial services "profile" for web services as possible.

In the messaging sub-layer is where we discuss items like industry standard messaging.  How and where to use each one and how to use multiples of them and translate, map and communicate between all of them.  This will likely involve a segway to BizTalk Server 2004 which is discussed in Part 4.  This is also an integration point to the user experience since many of those messages, be they data or status logs, will interact with the user and/or be generated by the user originally.  So messaging will talk about machine to machine and machine to human messaging.  This will dive deeply into the web services architecture referenced in my previous post today and how it relates to scenarios and patterns in financial services.

Lastly, the topic of integration is a very important one.  No system is an island and most financial firms have disparate systems.  So the need to integrate between applications and interoperate between platforms will be discussed.  There are good ways and bad ways to do this.  Posting text files to a file share is probably not a good enterprise messaging architecture, and so this section will have recommendations about common integration code and interoperability elements.  And in keeping with this layer, this integration sub-layer will be the unifying thread across messaging and web services to talk about the things that every application in financial services should have that allow other applications to talk to it in a standard way.  And in doing this, it can protect investments in previous technology by providing guidane on that abstraction layer for integration on top of current solutions.

OK, so after looking at what I was going to write and hearing some offline feedback I'm going to break this into several parts, so this might be like a five part series (some others interspersed) so just stay tuned.  Also, the limitation of these integration and architecture concepts are not limited to Insurance so the term will be renamed the Financial Value Chain, and is much more fitting with a converged financial industry.

So there are a number of layers to the Financial Value Chain from user components to server components and everything in between.  So I'd like to break these down into a few layers and discuss each one in a little depth.  These are not well named perhaps, so don't get hung up on the category name as that may change.  So the way that it is breaking down now is the following:

• User Experiences - rich, smart and thin clients are all part of this layer as well as the rich suite of Microsoft Office technologies as the "face" to the service oriented architecture and as providing the end user with the power and capability as well as the architecture that allows a user to be valued in the process and part of a collaborative infrastructure.  Also includes somewhat of a discussion about devices and hardware, although not much.  (Part 3)
• Web Services, Messaging, Integration - this is a large part of the architecture encompassing SOA, messaging, web services, workflow and EAI.  This is also where integration principles and interop with other systems will come into play.  This is where existing infrastructure interop and integration will be discussed.  (Part 3)
• Server Platform - the platform on which the SOA runs basically including the database architecture and features that should be taken advantage of.  (Part 4)
• Value Added Features - this layer is sort of a grab bag that is much more line of business oriented towards business level functionality that should be a core part of financial services applications and integration toolkits.  (Part 5)
• Documentation and System Support - in most every system there needs to be documentation on what, how and where APIs, SDKs, etc are located.  Also, this is where principles in service description and policy setting will fit to augment the services in the SOA.  (Part 5)

I'd be happy to take comments about pieces that you think fall into each layer, or even whole layers that you think may be missing.  Thanks for all the feedback so far.

Is it sick and wrong of me to say that I'm in LOVE with the work that is coming out of the http://www.ws-i.org (WS-I)?  Or perhaps "lust" is a better term.  Anyway you put it, this stuff is just fantastic.  And last night as I tried to get one of my kids to sleep, I was thinking of all of this great technical work within the context of customer service.

The "holy grail" of financial services for many firms has long been the "single view" of the customer.  That elusive picture of all the holdings, activities and plans for each and every account holder.  Such a picture helps up-sell, cross-sell and retain customers by providing them new products and services to enhance their experience.  But let's be real, when did you run into a customer that only had financial products at one institution.  And yet the portfolio of financial products that a customer may have definitely relate to each other whether or not they are held at the same place.  Charges a customer makes on a credit card may relate to charges on another account and be interesting from a fraud detection perspective.  Payroll deposits usually set off a whole workflow of payments, funds transfers and activities between institutions.

So let's look at some real customer service.  Let's assume for a minute that a customer usually has a "master" institution that they do most business with.  Let's assume that this institution wants to provide better customer service.  But let's also assume that the customer has products with other institutions (getting those air miles with credit card, great CD rate at local credit union) and that the customer is NOT going to move those products at this time.  Let's also assume that our customer uses the Internet for interacting most of the time with his/her master institution.  None of these assumptions are outlandish, so let's proceed.

In today's application space it's up to personal financial managers (PFM) to manage the connections to multiple financial data sources for a customer to view.  And this helps with bill payment, transaction recording, planning, etc., but it doesn't assist the target institution in making decisions for their customer that increase their "wallet share" or retention rates.

The first thing that the institution needs to do is adopt an advanced web services infrastructure.  This isn't especially hard since industry standards like IFX exist for common financial messaging elements and are only months away from releasing rich guidance on web services usage with those financial messages.  Common messages like credits and debits from accounts are likely targets for web service exposition.  Once that is done, a subscription architecture should be developed using WS-Eventing.  The institution then would publish (using their SOA architecture) events on their financial products for subscribers to view.  Of course this is all customer preference driven.  In the customer's Internet bank, they set up pointers to their other financial products, and from there preferences for event notification.  For instance, they might choose their debit and credit card lines be notified if there is an airline ticket purchase made from any product.  This would help fraud systems to have additional insight into their detection engines by enhancing transation patterns.  Or perhaps a customer's insurance company could be directed to subscribe to transactions of type "mortgage loan" and such an event would trigger an automatic insurance quote.  Some of the greatest customer attrition comes from disconnects in those processes.

Clearly there are implementation details to flesh out and nothing should be done without some business rules and privacy/security applied, but this is the direction that financial firms should be looking in as a possible avenue and business justification for a flexible standards based web services SOA infrastructure.  I just want to know what ever happened to good old fashioned check kiting....

Picture this…It’s the 1980s and Reaganomics is in full swing.  Computer hard drives are about the size of a flash memory stick and modems are barely pushing the 14.4 envelope.  But I’m a business and I need to connect electronically to other businesses.  And I need to send them a data file that from today’s perspective hasn’t changed much in size.  But in the 80s I’m not perpetually connected to a network, and disk space, not price feasible.  Standardized connectivity, transactable messaging and security are not en vogue.  Enter the VAN market.  Someone to sit in the middle, catch and store a message from someone hold it for someone else, log it, and if they’re really ambitious transform it into something else.

Flash forward to the world of today.  Organizations are ALWAYS connected to the Internet, disk space is plentiful and connectivity speeds are lightning fast.  Standards are rapidly being adopted.  And yet VANs are still there, still sitting in the middle…and going forward, mostly costly, proprietary and redundant.  But what is the alternative?  Large organizations can’t afford to connect individually to thousands or end points using application integration technology of yesteryear.  

So how about SOA?  Coupled with rich transformation engines like found in BizTalk Server 2004, connectivity tools found in the same and the ability to express services in a service oriented architecture using web services, and now you’re talking.  Even some VANs recognize the need to do this in their own infrastructures now acting as web service hosting proxies for their customers.  How about the customers just doing these themselves?  And where there is a need for connectivity to many endpoints leverage custom application architecture or packaged application with thin or smart client architecture backed by the web services sitting on the SOA.

I’d challenge financial firms to take a hard look at their investments in their VANs of choice.  Could they accomplish the same thing with newer technology?  Look at the money spent (connection charges, storage charges, data transmission charges), and if applied elsewhere, do you end up with a more flexible infrastructure for the future?  

Thoughts leading up to a holiday weekend….