Showing posts from January, 2008

Head Tracking for Desktop VR Displays using the WiiRemote

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 ProjectsAligning Project Portfolio of IT StrategyIT Organization Structure to for enabling Business AgilityEstablishing Enterprise Architecture TeamBlueprinting Information Architecture and BPM andService Engineering ProcessWhat 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 Enterp…

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 e…

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 represe…

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