Banking on SOA and .NET
Here is a brief one-pager of what I found interesting about a Case Study on a significant SOA project at a large Australian bank.
The CommSee application started off as a CRM application. However, CommSee became a single platform for delivery of business functionality to the banks user community. I suspect this is the world’s largest example of scope creep !! (see below for a possible explanation).
Architecturally there are many parts and modules in CommSee. However, two major layers stand out to me:
1. A front-end container which brings together all the UI pieces used by the business including legacy VB6 applications and new CommSee Winparts.
2. The Services Oriented Framework Architecture (SOFA)
Both the front end component and the server side were built using .NET technology from Microsoft and the application serves some 30,000 users.
The front-end container may be interesting for any bank, or other large corporation, with a similar User Interface legacy (i.e. scattered across many technologies like Java, HTML, VB, ...) or for those who wish to bring users to their work through a single window which provides rich user experience. The mini apps in the container are developed as Winparts which can be orchestrated tog ether to deliver a specific function. Legacy user interfaces are brought into the container using DLL injection.
The SOFA framework is interesting from a number of points. It shows how SOA services have been delivered by the bank as both “private” (directly needed by specific WinParts) and “public” those services which are most likely to be re-used across applications. Also the bank used IBM’s IFW to help define the interfaces to the public services. Some “public” services required state management as they are exposing long-running transactions. Biztalk Server was used for the necessary modelling, orchestration and state management. Oh yes, as a large bank there are of course many mainframes running critical line-of business applications. Integration with these from the rich user interface to the mainframe is through Microsoft’s Host Integration Server .
About the scope creep question
So how come it was acceptable to the project team to have the scope go apparently out of control - from CRM to what CommSee is today. This leads to the delivery approach of the team which was particularly agile. Vertical drops through the stack i.e. WinPart in the UI through to underlying service and database were delivered for specifically focussed functions one at a time or by a single team at a time i.e. slivers of functionality. This allowed a quick turnaround to end users and delivery of function. So, my guess is, that the apparent scope creep has to do with the fact that the team were “delivering” and therefore received a mandate to keep on going.
The trade-off with the above approach is that can be many services that are not necessarily as generalised and reusable across business function as they could potentially be. Then again, many other projects under-deliver because of too much navel-gazing. The classification of those services as “private” does imply that this was a deliberate decision to allow for quick delivery to the business. The discovery of a re-usable service could always result in it being promoted to “public” in any case.
Both the UI container and the SOFA layer were built on .NET and where architected in such a way as to position the bank to take full advantage of both of Windows Communication Foundation (www.msdn.com/wcf) and Windows Presentation Foundation (www.msdn.com/wpf)
In summary, there are a lot of interesting aspects to the CommSee application: the SOFA layer, the UI container, the use of IFW, the use of .NET technology and the development approach. If you would like to read more have a look at the full case study at : http://msdn2.microsoft.com/en-us/library/bb190159.aspx
