Greetings all...

So after nearly 5 years of focusing on the finance sector and really enjoying every minute of it...the time has come to expand my horizons and take the next step in delivering great products for Microsoft.  So as of very soon (date TBD) I will be moving to a Program Management role in a new product being developed in the Office division.  I am super excited to say the least.  I can't really talk about what it is, only that I know it will add tremendous value to all sizes and shapes of customers.

So what of Financial Services?  Well, not really sure to be honest.  I leave behind a history of some great initiatives that I was able to lead and that still survive, like the Insurance Value Chain.  The IVC which was invented by Kevin Kelly and me, still lives and will be taken to the next level by the capable hands of Kevin and his new colleague Dan Woodman.  Dan and another team member Stevan Vidich are the new technical brain trust for Financial Services for Microsoft and so please watch their space for developments.  Their abilities coupled with the business savvy of Kevin continue to dwarf every other Finance focused team at Microsoft.  I know they'll do great work.  As for the Architecture Team, I'm sure they'll find my replacement, but given the ever shifting goals and deliverables, I can't really tell you what they will focus on, what standards they will support or what the charter will be.  With so many resources across the company focused on the Financial space, I hope that the value to noise ratio increases measurably.

If you have an questions, please feel free to mail me via this blog, which I'm assuming will live since I can't figure out how to delete it.  :-)

Best of luck to everyone out there....

- Josh

Yon were the days when the term “architect” was a much proscribed and well defined career.  Gaunt, squinty individuals hunched over drafting tables with t-squares and compasses crafted the great works of art found in today’s building infrastructure.  Today, as with many terms, the trade is watered down with the advent of electronic media, computing and other technologies.  Each self proclaimed thought leader or innovator in their field becomes an “architect” of their trade or practice.  But there are few trades that are more similar than that of software architecture and building architecture.  The kinship of Frank Lloyd Wright and Martin Fowler can be seen in the timeless designs embodied in structure and software solutions.  And it is that metaphor that I would like to explore in some detail.

As with many youth, during my college years I had the chance to be employed in a number of fields.  To this day, one of my all time favorite trades was that of a foreman on a construction crew.  We built custom homes in the Rocky Mountain area, they were beautiful.  I loved doing the work, fresh air, sun, exercise and in the end a lovely structure.  Several years later I moved to the other side of architecture and design.  It was very fascinating to see both sides of the equation firsthand and realize the liberties and constraints that each role was allowed in the process of construction.  As I look back now as an architect in software, I can see the same role distinctions and implementations.

Abstraction is a wonderful tool for an architect.  To an architect, many of the implementation details are not something they concern themselves with.  Positioning of nails and brands of power tools are something left to the skilled laborers and tradesman.  The architect rises above this.  To them, they see a design, a vision, and communicate that through specifications, drawings and other artifacts.  In fact, these very artifacts range from high level vision reminiscent of artwork all the way down to detailed exploded views of sections of the structure.  And in each levels of these specifications are detailed the measurements, materials, and relationships to other segments of the architecture.  From these, abstraction provides the flexibility to the tradesman to determine the type of tools and sometimes the brand of material to use in order to accomplish the job.  And most importantly it allows the general contractor and financier the flexibility to make pricing decisions based on cost of materials fitting the plan.  Abstraction provides the architect the ability to separate from these implementation concerns in order to accomplish a pure and robust design.

Software architecture as we will see is identical in form and function to structural architecture.  Software architects will use the same abstracted separation to create plans that are not bound to specific tools or technologies.  This allows them to create architectures unfettered by manufactured constraints not core to the architecture.  To them the details of method calls and programming languages are not essential to the architecture.  What is essential is the system as a whole, the overall functions needed and the criteria under which the system can be called complete.  The software architect also uses plans to communicate.  These, unfortunately are not in a canonical or standardized form.  They may range from a single piece of paper or whiteboard sketch to a grand vision laid out in books.  In the end, the architect must take the requirements from the customer and with the project manager and development leads optimize resources to provide what is expected.  Between all parties there is symbiosis and conflict as each level participates in the implementation.  But above petty details the architect rises and is able to give real time adjustments to the software system in design to accommodate the issues brought to bear by the developers.  These planning steps and relationships are a key part of the architectural experience.

Planning with boundaries

A common misconception says that wide open space and no constraints are architects friends and that somehow out of a completely blank canvas the architect will create something fantastic.  This is not the case.  The architect deals with what the world knows as definite boundaries.  Those boundaries are things like price constraints, area, elevations, environmental concerns and function.  These boundaries drive the end result by imposing on the design and forcing the architect to either work around or incorporate the boundaries into the design.  A rather whimsical example of this is a tree house.  The architect of the tree house uses the boundary of the tree to enrich the design and function through incorporation.  On the other hand, the lack of acreage in inner cities causes architects to design vertically, being constrained by the hard boundary of square footage by mandate.

Architects use boundaries to plan and optimize.  Architects start with a finite almost raw space, a fixed area with other constraints like easements, utilities, curbs, public ordinances and zoning restrictions largely unseen to the naked eye.  Taking all of these factors into consideration the architect creates the base platform from which to operate.  At the same time, he will consult with the owners of the space to determine form and function.  The platform may or may not be affected by the decision in this process, but these discussions do assist in the overall planning of the structure.  Throughout, the architect is able to maintain an amazing job of using all this information to communicate a grand vision of the project. 

One of the greatest skills that an architect has is to be able to think in four dimensions.  He is able to visualize the structure from the raw foundation to the final shingle, as well as see these items coming together along a logical timeline.  Using this four dimensional viewpoint the architect creates plans for every tradesman that takes part in the construction process.  The architect can communicate from the high level vision of the structure as well as decouple the parts of the structure into usable diagrams and plans as a part of the whole.  Throughout this process, the boundaries constraint the measurements, materials and time required to complete the steps.  And lastly, one of the most important things that boundaries provide is predictability.  While not directly involved in all of these decisions, the architect’s output definitely influences costs.  With appropriate boundaries these costs can be estimated and controlled at macro and micro levels.  From an engineering perspective boundaries provide predictable scale up and scale out points and allow the structure to be engineered correctly with the right materials and placement of structural elements.

The downside to software is that it is just that…soft.  The biggest risk to any software structure during the build process is what is called feature or scope creep.  This is analogous to the blank canvas vs. the constrained environment.  A common fallacy by those not familiar with software is that because it is soft that there are no boundaries and that they only constraints are time and development resources, and that simple application of those resources will yield correct results.   This is not the case in enterprise software systems.  Like physical structures, enterprise systems start with the same constrained platform.  These include database sizes, disk space, servers, bandwidth and transaction throughput.  These raw boundaries, not tied to any product implementation, are taken into account by the architect and are usually communicated to him by the owners of the business and IT infrastructure.  This doesn’t change his vision of the overall system, but may alter the design nuances to accomplish them.  But make no mistake; many of these are hard boundaries, just like concrete and acreage.  The software architect turns these boundaries into advantages by leveraging across them to service multiple solutions as well as optimize usage of common patterns to reduce redundancy.  In the end, software boundaries need respect just like walls and foundations.  Once a piece of software is built, if there is additional need the architect can start anew by planning properly engineered additions or additional applications. 

Through this iterative development and delivery process the boundaries not only help control cost and features, but also help solidify delivery dates and allow management to declare completion through reduced ambiguity.  Without boundaries, these things could not be accomplished.  The features would change or grow at the whim of users, managers and development.  The budget would be unfixed and hard to manage and just like in construction because the finished product was so poorly defined, there would not be a chance for a certificate of occupancy.

From Design to Done

Once the proper boundaries and constraints are identified and established, the design process can begin in earnest.  For the architect, this is where the real artwork lies.  The architect begins with a high level abstract or vision of the structure.  This vision will drive certain designs and patterns into the architecture.  For instance, a residential construction will be classified by a style of home like Southwestern which will then dictate certain features, like tile roofs and stucco.  The high level functions of the structure dictates not only look at feel, but structural concerns as well.  A somewhat tragic example of this correlation is found in the library at the United States Naval Academy in Annapolis, Maryland.  When designed and built it was a grand structure, with the space to house classrooms, labs and millions of publications.  However, the architects failed to take into account the full weight of the books when designing the structure and as a result the occupied library began sinking slowly into the soft sediments of the river lowlands.  Mistakes like those are avoidable by incorporating functional concerns into the design process.

From the high level vision the architect drops down to the creating the platform serving as the foundation.  The foundation serves as the basis for the structure.  The entire load bears on the structures found therein.  This includes beam structures, cement footings, steel and slabs.  These foundational elements may be aesthetically designed, but more often than not, they are solely structural. 

Enterprise infrastructure behaves in very much the same manner.  The system is likely constrained by the hosting environment.  It is made up of a number of different things, but all based on the premise that it costs resources for hardware and platform software.  This constrains what can be done on top of this platform.  The richness of the platform software and hardware will also determine in some respects the load that the system can handle or specific guarantees of reliability in very much the same way the structural elements of a building will.  The software architect takes all these things into consideration when designing a system.  Full disclosure of the known elements of the architecture, functions and boundaries to the architect is important at this point.

At each level of structural design, there are details given about overall dimensions as well as details about methods or patterns for segments of the structure.  The architect will typically detail exploded views of things like footings, headers, beams, windows, eaves, siding and rooflines.  So in addition to the broad floor plan which helps lay out the entire floor in a cohesive manner, the tradesman is given instruction on special ways to construct the features of the house that are non-standard or subject to interpretation.  These details may also be required by special building codes unique to the locale or type of structure.  Often these special features or focused sections of the plan call for specialized skills or materials.  This also assists in planning resources and scheduling.

Following a logical sequence the architect moves from bottom to top of the structure detailing everything from foundation detail to soffit trim.  The plan implies a schedule and sequence of events; however some of these items are left to the tradesman as we shall see.  During the construction phase, the architect stays involved in the event that there are changes in the plan or complications encountered.  One such structure where I was leading a crew found just such a change.  We had just finished framing the first floor of a large custom home and were getting ready to start rolling joists on the second floor.  At this point the home buyer decided to change from a smaller bathtub on the second floor to a large Jacuzzi style bath with intricate tile work.  The plan had not called for any reinforcement in the floor joists on the second floor to handle the load of that much water.  So the architect was engaged to make the changes and we found that we were then had to use laminated beams and doubled joists to reinforce the second floor.  This also impacted the already done first floor walls as those beams needed bearing points down to the foundation.  So the changes were made in the walls in order to handle that load.  In this example, the architect was needed to fix and adjust the plan and working with the tradesmen made the changes in the appropriate point in the construction.

It is fair to say that the software architect is a little more hands on during development than the structural architect.  But throughout the process, he is just as engaged in the design process.  Starting with the high level vision, the software architect communicates the goals, vision and function of the solution or enterprise that is being built.  These guiding principles will not typically change.  What may more frequently change are the avenues and implementations used to accomplish that vision.  Software has the added luxury of being a fair bit more pliable allowing some flexibility in the design and implementation in more real time.  This is one reason why the architect stays more engaged throughout the project.  While building a purchasing card management system for the United States government, the architecture was geared towards transaction processing and transaction monitoring.  However, the initial architect had failed to accurately predict the sheer volume of data that would be needed to roll up into reports for the government.  When testing determined that the transactional database system would not handle the load adequately, I found myself devising a new architecture for analysis and reporting to fit with the current system design.  Many of these decisions are made real time, and the software architect uses the same exploded views of segments of the systems in order to detail special circumstances in applications and systems. 

While usually not covered by code mandates or regulations, software architects derive design from the same patterns and standards that are commonly used in the industry.  Some things like security, database design and message exchange can be found to be canonical and fungible between enterprise structures.  Since these are generally accepted in the industry, it is simpler to find skilled technical staff to develop to those standards. 

In both structural and software architecture, the process of design is similar.  It begins with a vision of the system or structure.  This vision maintains state throughout the creation of macro to micro plans for the creation of the structure or software.  Critical to the architectures are the detailed views of segments of the system drawing on standards and elucidating details needed for compliance to codes or accepted patterns.  And at the end of the day, the architect relies on the ability of the tradesman, the developers and engineers to interpret the plans to build a robust system or structure.

The Architect and the Tradesman

Hammers, screwdrivers, nail guns and drills...some of the tools of the skilled tradesmen in construction.  Legion is the variety of hammers available both for varying functions as well as personal preference.  My first day on a snowy jobsite at the base of the Rocky Mountains involved breaking in a 32 ounce framing hammer.  I remember being the envy of almost everyone on the crew, everyone except the general contractor.  His preference was to carry a roofing axe, and after watching him at work I understood why.  And after building many custom homes, I came to understand the relationship between the architect the tradesman and tools.

Remember the principles of abstraction that make the architect so effective.  The ability to rise above specific details of implementation allows him to purify the implementation of his vision.  The tradesman on the other hand has a mixture of constraints and freedoms when implementing the architectural vision.  On the one hand, the tradesman is generally free to choose any number of tools needed to get the job done.  Skilled tradesmen will use the correct tool for the job, but at the same time will definitely have a favorite tool or tools for certain functions.  I still use the Hitachi pneumatic framing gun over all others because of the way it feels and operates.  And of course for most intensive nailing operations I prefer that over my two pound hammer.  On the other hand, the tradesman is not always given the freedom of choice as to the types of materials to use.  These are usually a combination of decisions made by the architect, like in the case of types of floor joists, structural elements or lumber dimensions or they are made by the contractor and financier of the structure for budgetary or code reasons.  The tradesman doesn’t have the luxury, except in extreme cases to question the types of material chosen; they are just expected to follow the specification on the use of the material.  In this sense, the tradesman is very much subservient to the vision of the architect.  They even may not agree with the look and feel of the structure or even the function, but they know how to implement the detailed plan. 

The architect and tradesman do not interact all that much.  This is one of the benefits of the detailed plans, is that the architect can move on to the next project and the tradesman can construct to the specification.  Without this detailed specification the architect would need to be onsite directing the work effort on a daily basis.  This is slightly different from the relationships between architects and developers in software.  By contrast these players will often sit side by side and flesh out details of the implementation from the architectural plan.  Due to the “soft” nature of software architecture things can be this fluid, but may not need to be as more rigid specifications and more importantly patterns emerge for software design.  Both of these items will bring the software architecture to implementation cycle much closer to that of structural architecture and development.

Architects are not tradesmen and vice versa.  Very rarely will you find an architect instructing a skilled framing contractor on how to nail one piece of wood to another.  There is an inherent trust placed in that skilled laborer that they can perform the function needed to complete the project.  That same trust should exist between software architect and skilled programmer.  In fact the architect may not even know exactly how something will be coded, just that it will and it will deliver on the specification.  The tools that the programmer uses may not be apparent or known to the architect either.  They may range from full development suites to simple text editors, and are determined both by personal preference as well as mandate by a project manager or IT infrastructure.

The loosely coupled relationship between the architect and the tradesman or programmer exists to fill a purpose.  It optimizes the work that both can perform and allows them to deliver without constraints on their ability.  It also decouples the architect from the pedantic details of implementation as well as allowing the programmer/tradesman to accelerate their work by using the predicable and repeatable patterns detailed in the plan, with tools they have familiarity with.

So Why Architecture?

The metaphor I have used has been building to answer this question.  Why is architecture important?  Why do we have architects?  I hope that some of those answers are obviously demonstrated herein.  It all boils down to delivery.  If there were no architects, there would be no delivery.  Through the use of proper boundaries, the project success criteria can be determined.  Those boundaries provide structure to the development, and signal completion.  Many software application development projects fail due to improper planning and boundaries.  This is typically seen when small prototypes move directly into production.  The prototype will perform well for its function, and incorrectly assumed to be able to just scale right up.  This is analogous to a contractor building a one story single family home and then deciding to just add floors with no additional structural modifications.  Correct architecture avoids these issues through planning, proper design, and coordinated execution with skilled developers and tradesmen. 

Well, my first blog of the new year.  I'll tell you something, the holiday season brings with it so much family time and other frenzied activity that I have been remiss in posting.  But that will change as the new year brings some exciting developments in technology, standards and service oriented architecture. 

Now I'm a firm believer in goal setting and resolution making.  I'm not saying that I'm perfect at keeping all the goals that I set, but my view is that if you never set any, you'll never be able to measure what you did or didn't accomplish.  In any event, one of the things that I do every year at this time is to look at my finances, my investments, my debts and so on, and set some goals, re-balance my portfolio and get on track for the new year.  A few years ago, I got my hands on a tool that has changed the way that I view my finances.  You see, I'm a really visual person, pictures say about 10,000 words for me.  This tool, written by Impact Technologies (http://www.advancedimpact.com) is a set of stencils and web services for Visio that allows me to visually model my accounts and cash flow over a period of time, coupled with web service stock look ups and Monte Carlo Simulations for investment return and so forth.  What I end up with is a graphical flowchart with the ability to see where my money goes from account to account and the ability to run that model over a period of years as well as output EVERYTHING to Excel showing month by month transactions between all accounts.  They called this tool Financial Canvas.  And like I do every year at this time, I used it again to model the next few years.  Now, with any confidence in the stock market (sheesh, did anyone else feel bloodied by this last week?) things might be looking good.

But the whole experience got me thinking, yet again, about the way that I deal with my financial institutions.  I can model the crap out of my finances, but in the end it's all up to me to execute that model.  I have to transfer the funds, sell the stocks and pay the bills.  What I'd really like to be able to do is have a standardized model that I can hand to my bank and brokerage and just say "just do this", and have them do it.  They would automatically create limit orders for stocks as per the model, transfer the funds when appropriate, etc.  And this is the exact value of an implementation of standards.  For a system to be able to identify "objects" as accounts or stock owned, and workflow in a standardized manner.  Using service orientation, the executors of that "plan" would then also make a pick list of transactions available that would facilitate interaction between those objects.

And now, my plea...this is a personal passion of mine.  In the work that we do with financial companies, we long for the day when the object, transaction, and workflow can come together in a flexible manner.  And all for the CUSTOMER, to add value to the way that they get a return on their investment.  Is there anyone willing to take on this challenge and step up to be a leader in flexible customer service?  Time will tell, I suppose. 

Happy New Year to all and please watch for exciting blogs and updates here on this site.

- Josh

I'm finally done with the seasons of standards meetings.  I just wrapped up the ACORD Subcommittee meeting in Ft. Lauderdale.  I have to say that I'm glad that I'm done with all that.  One thing that strikes me about standards and application design is how much people forget about the flexibility in programming, message design and enterprise architecture when they try to preserve legacy infrastructure or ways of thinking. 

One of these areas is the ever present function we now lovingly refer to as "batch".  The funny thing is that I've been hearing for years now, that "batch is hard" or that "you can't do batch with foo Microsoft product".  I even heard it this week regarding the ACORD XML message specification.  I heard someone say that they couldn't cobble together a batch message load using XML.  I thought that wa the most absurd thing that I had ever heard.  Perhaps one of the issues is that the size of a larger XML document does not lend itself to being strung together into multiple messages for a single batch message.

As industry standards are developed, one thing that they must keep in mind is that a more granular and composable approach allows batch messages to be more concatenated into a batch message without overloading the wire with data.  Second, a properly architected service layer would allow consumers to request just the data that they need at the time that they need it thus reducing the need for large message based batches with largely unnecessary data.  Smart client architectures can assist with that.  I just don't understand why batch processing kicks everyone's butt.  So let me set the record straight.  SQL Server 2000 can do batch, DTS allows a number of ways to load extract, transform and load data...and that's only one feature.  BizTalk Server 2004 can support batch...through workflow, message creation, and adapter infrastructure.  .NET code can also build a batch environment...so stop sweating this.  If you really have to do batch, just program it.

Now, I thought I'd give some more random questions and bullets that I thought of at the ACORD meeting.  These may not make much sense to those that didn't attend or don't engage with ACORD, but I'll try to give some context.

• In the version 2.0 creation process, there seems to be an outstanding issue as far as how finely or coarsely you factor a service namespace.  They seem to be using a CRUD method grouping all business units under CRUD macro levels.  Would perhaps a business level designation be better or just an infrastructure that supports both?
• The concept of one way messaging is something that still needs lots of work.  Sure there is a need like eventing and notifications, but perhaps some of the WS-I work is best suited there, and not a custom "framework".
• When are we going to kill AL3....PLEASE !!!!!
• ACORD has a concept of "Service Provider Extensions"...could these be better served using a WS-Policy infrastructure and not a custom schema redefinition scheme.  I'll have to look into that.
• When will we finally have a convergence of the specification data elements so that when ACORD says "FirstName" (for example) it means one thing and not three?
• ...and finally
• There does appear to be very little mainstream support for the SOAP w/Attachments direction.  Many of the historically active contributors to the process are not supportive at all and in fact willing to wait for the right specification to compose with a web services architecture...um, like MTOM  :-)

And that's it for tonight.  Now...back to Halo 2.

- Josh Lee

As many are probably already aware, the US Insurance industry suffered a major blow (not to mention TONS of market cap gone) this week in the filing of charges against a raft of executives for allegations of price fixing and other sundry schemes.  For those who wonder what I am talking about a good summary and financial analysis can be found at Jubak's Journal (http://moneycentral.msn.com/content/P97291.asp) on MSN Money. 

So I could gripe about the people or the industry that allowed this sort of thing to go on, but I do think that it comes down to a simple (maybe "simple") act of compliance.  In combing through the financial statements of the offenders in this case, doing a comparison and correlation of booked business, commissions paid and received this could be simply discovered.  Reporting infrastructure could easily be set up to have independant auditors mine for trends and anomalies.

But what about this in an SOA context.  We often think about transaction monitoring at the bit level, like whether messages were signed or whether they had this XML element or not.  But what about at the business level?  One thing that could result here as the investigation and remediation unfolds is the implementation of new levels of visibility into accounting books.  Standards like XBRL will become more important as appendages to financial web services.  Those appendages would then be able to capture trends that could be analyzed for compliance.  I could even see something like WS-AccountingPolicy surfacing for mandating that financially oriented web services adhere to a standard of financial reporting.

Now, more to the point of what insurers will do.  What if this case drastically altered the commission structure?  Someone sent me a mail about this, suggesting that this would cause yet more increase on process and messaging efficiency.  Turning commercial insurance placement into much more like personal insurance...and what is wrong with that?  Wouldn't that level a playing field for those that are smaller and more agile in IT and allow them to write bigger business because they can facilitate data capture and transactability in real time vs. easily corruptible human vehicles?  I tend to hope so.

Bottom line...maybe more regulation needed, but overall, let this be a seminal moment for e-Commerce growth in a very human process intensive business. 

- Josh 

Been a rough couple of weeks...kids, illness and events.  I have been remiss in posting.  We just finished the SAF here in Redmond this week and I will be posting some information and feedback in general here very shortly.

The season of standards will soon be upon us with IFX and ACORD both with upcoming meetings in Florida.  And at election time no less...maybe I can spend some community service time teaching Broward county residents how to vote.  :-)

One of the themes that came out of the Strategic Architects Forum this week is addressing the area of domain specific languages (DSLs) integrated with industry standards as a basis.  So I'll spend some time talking about that very soon as well as how that relates to a service oriented architecture.  I'd also like to explore some concepts behind service interface definition and the relationship to contextual key words and actions.  This will become key in building flexible client architectures to access those services.

And lastly, there are a few banking technical/business issues that I'd like to get off my chest.  IMHO, the only thing slowing the industry is themselves, so I want to address a few things that could add value to customer service and provide new ways to look at banking technology.  Especially in light of some new things that companies like Google are doing.  Should be fun.

Everyone have a great weekend and this next week will allow some great discussion.  Thanks to everyone who attended the SAF and please look for the regional events over the next 8 months.

I really hope that I am not alone in this line of thought, but I really hate the Presidential Debates.  I did debate back in secondary school and college, and to call these things "debates" is an insult to pillow and tickle fights everywhere. 

I don't know how anyone could make an educated decision about the election with this tripe.  The format and short strung together sound bites are an insult to even the average American's intelligence.  There is nothing that this debate delivers that you couldn't get by watching the news clips of the campaign trail.

No, give me a good Lincoln-Douglas style debate and not this namby pamby Q&A.  A good sound, well reasoned, and deep interchange of positions and statements.  If these candidates REALLY feel these things in their hearts (as they say) then they would have no problem with the other person grilling them in that Lincoln-Douglas format.  At this point don't the American people deserve that depth?

Oh, and BTW, "my" candidate won the pillow fight.  :-)

- Josh

In this final part of the Financial Value Chain series, I'd like to address, what I think can be the most exciting parts of the Financial Value Chain.  Up to this point, it would be fairly easy to call parts 1 through 4 a common infrastructure that can be used across a number of successful industry architectures.  Sure, there are some nuances to the server and services infrastructure that are unique patterns to the financial enterprise.  But in this layer are those features that are unique to a financial enterprise and some of the SOA principles that will take the financial IT ecosystem to the future in transaction processing.

Value Added Features

Probably not the best name for this layer, so bear with the silly name whilst I explain.  There are some things common to many applications.  Data descriptions of a customer entity, concepts of an account or policy and common transactions like debits and credits.  And when it comes to an operational environment, these are the elements that provide the interfaces for system management and business interaction.  Items like non-repudiation, logging and system configuration are found here.  But it is in this layer that you will find the SOA elements of a VAN (see previous post). 

Documentation and System Support

Every system needs documentation, help and description files.  The Financial Value Chain is essentially an SDK or API set, but from there is needed sufficient documentation so that someone can deploy and integrate with the solution.  But this also include usage of WS-Discovery for the publishing of the web services.  This layer will compose the elements that are needed for monitoring and management of the application.  In an enterprise system interdependencies between applications need to be well documented.  This type of data and standardization will also make it possible to begin to benchmark business applications for price and price/performance.  In this way, applications can optimize their fiscal stability by adding value in IT features on an integrated platform.

These core layers of the Financial Value Chain provide a holistic architecture from data description, enterprise services, user collaboration to serice management for the financial enterprise.  Also by making this investment in interfaces and enterprise services the financial enterprise or finanancial software vendor can insulate themselves from radical changes in technology by focusing on the features that add value to the business and allow seamless integration.  Stay tuned for developments in this area over the course of this year.