Thursday, January 24, 2008
Tuesday, January 22, 2008
- 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 .
Thursday, January 17, 2008
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.
Thursday, January 10, 2008
Wednesday, January 02, 2008
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
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.
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
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.
Tuesday, January 01, 2008
Note: This is not a comprehensive list. Source: SOA Practitioners Guide
A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...
The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differen...
One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed a...
It has been a while since I last blogged, especially after joining Intuit in 08-2008. For those not familiar with Intuit engineering cultur...