Wednesday, August 29, 2007

Online security - fix the source of the problem

Randy Janinda responded to my post from a while back, Citibank Hardware Tokens Defeated... at the exact time that Bank Systems & Technology talks about how Bank of America is attacking the weakest link in online security - user's desktops:

Recognizing that defenses are only as strong as the weakest link, Bank of America has moved to shore up an area that largely is beyond its control: customers' desktops. In a move experts say is a step in the right direction toward improving online banking security, the Charlotte, N.C.-based bank announced a partnership with Symantec (Cupertino, Calif.) in which the bank will offer the security solutions provider's software to online banking customers.


This is certainly a step forward, although it cynically just looks like a great marketing ploy by Symantec at this point (just another channel for promoting a 90-day free trial). And to Randy's point it does not address the hardest point to protect against - phishing - and fooling people into handing over their authentication. How can banks help customers protect themselves so that they don't have to jump through hoops to detect scamming websites? In an environment where software can be installed on a customer's PC, like BoA is trying to do with Norton, there must be software that can reinforce the browser against phishing attacks. This may have to be the next thing that BoA offers.

Technorati tags:

A post from the Improving New Account Opening blog

Monday, August 27, 2007

Component stack - a simplified architecture for applications

Its been too long, with lots of work, travel and vacation, apparently leaving me with no time to blog. I'm back, but a little rusty and jetlagged, so bear with me!

James Taylor posted today on Enterprise Decision Management Blog about a post by Roeland Loggen on his blog - BPM Suite as a component in a logical architecture. Roeland proposes a BPM-centric architecture that plugs into a range of other components to handle administrative type processes.

James suggests some enhancements to the architecture, largely to ensure that the Decision Platform can interact with the Complex Event Processing (CEP) and Business Activity Monitoring (BAM) components. I agree with his rationale, and would even take it a step further - every component in an architecture (that isn't pure technology) should be able to interact with every other, ensuring that really advanced business requirements can be considered, offering more and more business value.

As ever we should avoid point to point integration of every component in the architecture, instead components should offer services that can be consumed by one other, both for rigid (generic) use cases and to meet application specific requirements. Having SOA technology and a strong integration platform underlying the architecture seems like an essential requirement. SOA technology also provides the ability to host the final application as business services that can be reused in other applications across an organization or by business partners.

A benefit of taking a services approach is that generic architectures like Roeland's are simplified - they are effectively flattened; every component can benefit from every other and the architecture doesn't need a hundred lines showing the explicit connections between all of them since the connections are handled by the SOA / integration backbone. This backbone may utilize a range of technologies, and may be effectively hidden from view. Without fancy drawings, the generic architecture becomes a simple list of available components that have been plugged into the backbone, for example:

  • Business Process Management (BPM) - incorporating BAM and process analytics
  • Decision Management
  • Case Management
  • Content Management
  • Customer Database / Information System
  • Document Capture
  • E-Forms Management
  • All plugged into a SOA/integration backbone

Taking this stack approach allows business analysts to concentrate on using the components providing higher level business value in the most effective way - not the forced integration of monolithic products. Any particular business application can reuse the same architecture and technical backbone, and will benefit from platforms that are more interconnected out of the box. Specific connections (drawn on an 'architecture' diagram) now represent business use scenarios, and the value of each interaction can be easily seen, especially where new integrations may need to be built. Here is a simple example:

The application here is a fairly generic application processing solution, which shows an architecture that highlights the interactions between the components, already relying on the implicit (and invisible) technology backbone and any available services that are already in place. A different application could show very different connections, allowing the 'architecture' diagram and implementation to closely reflect the business value of the application. The technical architecture would be no different from before - a plain old stack implemented once and used over and over.

Picking a stack that can handle the high level business requirements, while being architecturally strong enough to hide much of the technology complexity, and still allowing the flexibility to meet specific application requirements across many different applications is hard work. Organizations looking to get the best value from their technology investments should look beyond simplistic 'drag and drop' and developer toolkits to ensure that new technology really can deliver complex applications fast, while allowing constant enhancement and new applications to be based on a common platform that can perform as needs grow.

Technorati tags:

A post from the Improving New Account Opening blog