Key Best Practice: Separation of concerns - the age old best practice!!!

Here I thought that reiterating the principles of separation of concerns would provide a great rrefresher.


It is my contention that architecturally it is a good idea to keep the persistence layer and the business logic layer separated just as it is to keep the presenation layer and the business logic layer separated. Especially, in the age of SOA this make a great deal of sense as it enables each layer to change independantly to enhance the overall agility and robustness of the solution and to increase the responsiveness to the business needs. Here I expound on the reasons for the separation of the persistence layer from that of the business logic layer.

A) Keeping the business logic from being comingled in the same objects that hold persistable fields (that are tied to the persistence store layout or database schema) is important as this separation of the persistence fields from the business logic allows the application/ component to deal with the changes to the database schema more efficiently. The corrolary is also true in that persistence related objects/entities are insulated from the changes to the business logic.

B) The separation of the business behavior from the persistence layer may have an added advantage of allowing the implementation and testing of the business behavior to remain independant of the implementation and testing of the persistence behavior.

C) In addition, these persistence related domain entities could become simple state encapsulation entities (DTOs) and could become the sole constructs that are traded/ exchanged between the persistence layer and the business logic layer

D) These state encapsulation entities (DTOs) could also be shared as parameters between components and/or applications and could be transformed into XML long as they all belong to the same business domain.


Your feedback is appreciated.

surekha -

Vendors need to incorporate SOA infrastructure in legay applications

The majority of the IT budget (over 80%) is typically committed to supporting the existing infrastructure and applications. Even though adopting SOA brings substantial value over the long term, the short-term impact actually increases the support cost in two ways.

First, IT organizations will need to procure additions infrastructure components such as the Enterprise Service Bus, Registry/Repository, SOA Manager, SOA Governance tools, etc. Products like these not only requires upfront initial investment, it also adds one more layer of abstraction (hop) in the existing environment impacting the end-to-end performance.

Second, the support organization shall need to increase headcount and hardware infrastructure to support this next generation of infrastructure.

Even though most of the existing packaged applications are re-architecting their solution to run on the SOA platform, we are still years aways from wide deployment of these next generation applications.

It for this reason, it may make sense for the packaged application vendors to actually focus on retrofitting their previous versions of applications with the SOA infrastructure such as replace proprietary work flow by BPEL or XPDL, service enable (better) some of the business processes/services. It should be done in such a manner that the developers could still use the existing (proprietary) tools, keep the current functionality as is, limit functionality changes and roll this out as a patch release for the existing ERP, CRM applications.

This approach shall accelerate the adoption of SOA within and enterprise. In addition, enterprises shall be willing to pay incremental support to get this capability, a win-win for both the vendors and their customers.

Key Learnings: Overcoming IT obstacle

I used to get offended whenever anyone stated that IT was an obstacle for Business, most probably because of I have been part of IT twice in my career. After giving this some thought following are some of the approaches IT could take to overcome this perception.

Business and LOB-IT agree to adopt agile, i.e. a small joint team of IT and business to rapidly deploy applications. IT Operations object and demand that the team follow the traditional application life cycle (at least for the releases) so that they can meet the business SLAs.

• This may make sense for transactional systems that are business critical - but then again, if managed right even such applications could be deployed using the agile approach. One potential approach would be to provide a dedicated set of environment (including in production) and/or include IT operations in the agile team. This enables them to rapidly deploy new capabilities every few week.

A small business team developed or procured an applications which suddenly gains a lot of momentum within the enterprise. As IT was not involved in any of the decision making, it refuses to supporting or maintain the application stating that it may not have the skill set, resources and/or the ability to support it. This frustrates the business as they see this as IT slowing down innovation.

• IT should work with business to find a solution. Couple of options include - outsources the maintenance to a third party (including hosting servers outside the IT's data center) OR IT provides only lights-on SLA for such applications.

Business comes to LOB-IT requesting a data mart - basically extract some key information from multiple systems for reporting purposes. IT comes back with a huge proposal that includes procuring hardware, reporting tool licenses, support headcount, etc. a number that business definitely cannot afford.

• Observed this across multiple large enterprises - business extract the data from sources and sends it to a third party (small business) who have the expertise to create the custom reports as well as support the business. IT needs to figure out a ways to support such business needs - otherwise, it risks being irrelevant for rapidly developing custom reports for the business.

Business is interested in rapidly rolling out a business capability with a time frame and budget in mind. IT comes back with traditional approach of selecting and deploying packaged applications with both an unacceptable time frame and budget.

• Work with business to identify a SaaS provider and either pull all the data in periodically or identify and develop the integration between the SaaS provide and the exiting enterprise applications.

These are just some examples - additional anecdotes are welcome.