Head Tracking for Desktop VR Displays using the WiiRemote

Some worth watching

Key Learning: SOA forcing IT organization to focus on their core competencies

Over the last few months I have had the opportunity to talk to some of the IT organization in the silicon valley and am happy to report that most of them are either in the process or have already adopted SOA. By adopting SOA - it has forced the IT leadership to focus on their core competencies. Most of them are primarily focused on the fundamentals such as:

• Selecting Strategic Projects
• Aligning Project Portfolio of IT Strategy
• IT Organization Structure to for enabling Business Agility
• Establishing Enterprise Architecture Team
• Blueprinting Information Architecture and BPM and
• Service Engineering Process

What was surprising to me was that even though most of the us early adopters have shared our key learning and best practices on blogs such as this, most IT organizations are still struggling to focus on their core competencies - such as defining the roles and responsibilities of each teams, separations of development and support teams, communicating IT goals to all teams, establishing Enterprise Architecture teams and defining and enforcing the application life cycle (services life cycle come next).

If this is the state in the heart of the hi-tech industry, woder how it is out there in other industries. It would great to get the feedback on what the rest of you are observing .

- Yogish

Created Google Groups to continue the discussions further

As we now a number of subscribers for our blog we have gone ahead and created a Google Group to help facilitate discussion within the subscribers. Please do join us to have a more detailed discussion on any of these topics by clicking on Visit this Group. Plus have interesting conversation with your peers in the industry.

- Yogish

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 -

Ideal IT organization structure for (SOA) enabling Business Agility

Based on some of the conversations with my peers as well as reading about the transformations happening in the IT organizations - following is an overview of an ideal IT Organization. This is more at a functional level and the reporting organization would be specific to their own business models, culture and of-course politics. Additional details are available here.

- Yogish

Key Learnings: Canonical Models vs. Domain Models

In this blog my attempt is to provide some definitions and in turn to get feedback on the differentiation between the parameters traded between a service consumer and a service provider (Canonical Models) vs. the parameters traded between the various internal architectural layers of an application (i.e. the Domain Models).


Canonical Models
Example of canonical models - Customer Preferences, Supplier Profile , Vendor Service Offerings and Accepted Service Bid

1) Shared as parameters for trading between service consumers and service providers
2) In SOA context these are typically transformed into syntax agnostic and platform neutral XML
3)Business Service usage context is associated (for example, information about a quote vs. a final offer that has legal implications is embedded in the canonical model)
4) No real business logic is embedded giving service provider the freedom to alter the behavior without breaking the service contract
5) Cross-business domain relationships formulated by representing multiple business concepts are included so that the consumer can avoid making multiple remote calls

Domain Models
Example of domain entity - Purchase Order and Customer

1) Shared as parameters between persistence layer and business logic layer
2) May or may not be expressed as XML especially if traded within the business domain applications/components
3) Domain context and domain internal relationships are captured
4) Domain specific business logic may be encapsulated as the model is traded within the business application or within the business domain. Also, the business logic in the domain entity has relevance internally to the business domain alone.
5) Single business context and only relevant amount of information in terms of attributes and relationships are represented so as to avoid hydrating a large volume of information into memory.


Thanks in advance for your feedback.
surekha -

Business Process vs. Business Service

The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differentiate between these concepts in the following manner:


Business Process
1) Triggered by business events
2) Issues a series of business actions that could involve the invocation of one or more granular business services
3) Interactions involve execution of a business activity that is representative of a value chain or is a core part of a value chain in the enterprise

Business Service
1) Typically triggered by a request from an online consumer or a single business transaction
2) Issues a single business action for the most part
3) Interactions involve the execution of a single business function or an inquiry against a single core business entity

Your feedback is invaluable.
surekha -

Simplified Common Vocabulary

Wishing everyone a very happy new year. Last year was very good for the IT industry with both business and IT organizations investing in both SOA and BPM. There are still a lot of organizations just starting to embark on the journey of SOA and felt that it was important to once again list the description of some of the most common vocabulary used by the Architects, Project Managers, Business Analyst, LOB, LOB/IT and IT Operations.

Note: This is not a comprehensive list. Source: SOA Practitioners Guide