In today's marketplace there are several specialized products catering for specific business function. As each product is trying to extend into other areas, there is a lot of overlap of functionality.
Architectural decisions are
1. Build - Tailor made solution for the business problem
2. Buy - Buy one product - Implement, configure and customize the product for the business needs
3. Buy best of breed products and integrate to provide solution for the business problem
There is a little catch in the option 3. Some times, the technology stacks of these best of the breed products end up incompatible and cause major issues to business after integration. The problem resolution takes generally longer than single product solution.
Friday, October 26, 2007
Friday, October 19, 2007
Services and BPEL
Of late there is a lot happening on the service oriented architectures (SOA)
Approximately two years back, when the UK gas distribution networks have been sold to different private owners by the regulated business there was a need to "integrate" the business processes uniformly for the metering business work management applications where I first got into the this.
Is this new? when the c language programs were written a function used to provide a specific "service" to the calling function. It was call by value or call by reference and use of pointers that time. Later in multi processing systems the interprocess communication (ipc) was used to coordinate between the processes running on the same computer. Further to that the remote procedure call (rpc) came up. Multiple standards have come up from the rpc technology and with the advent of xml it finally transformed as web services.
SOA is not actually a software thing it is more of an architectural pattern. designing the business process as a loosely coupled services and orchestrating the web services using the business process managers is synonymously called as SOA.
The beauty of SOA's success is in the appeal of legacy wrapping. No need of re-writing the legacy application. One can still use the core COBOL back-end program with a wrapped adapter in a web service orchestrated SOA environment.
Care must be taken while designing and defining services and the work flow. Properly designed business processes with the aid of BPEL looks very promising for the future.
Approximately two years back, when the UK gas distribution networks have been sold to different private owners by the regulated business there was a need to "integrate" the business processes uniformly for the metering business work management applications where I first got into the this.
Is this new? when the c language programs were written a function used to provide a specific "service" to the calling function. It was call by value or call by reference and use of pointers that time. Later in multi processing systems the interprocess communication (ipc) was used to coordinate between the processes running on the same computer. Further to that the remote procedure call (rpc) came up. Multiple standards have come up from the rpc technology and with the advent of xml it finally transformed as web services.
SOA is not actually a software thing it is more of an architectural pattern. designing the business process as a loosely coupled services and orchestrating the web services using the business process managers is synonymously called as SOA.
The beauty of SOA's success is in the appeal of legacy wrapping. No need of re-writing the legacy application. One can still use the core COBOL back-end program with a wrapped adapter in a web service orchestrated SOA environment.
Care must be taken while designing and defining services and the work flow. Properly designed business processes with the aid of BPEL looks very promising for the future.
Wednesday, October 10, 2007
Quality Measurement
Quality is very important for the success of any software project. This is an accepted fact The issue here is how to measure the quality.
Time, Cost and Quality is the well known triple constraint. How to workout this is taught and practiced by several project management methodologies like PMP and Prince2 etc.,
It is a general feeling that Quality is all about Measurement, defining the measure, collecting the data, plotting the data against an upper and lower bound and analyzing the results when there are cases of data falling outside the tolerance limits.
What is wrong with this? Nothing. But the key lies in defining the measure. There are several factors of the quality :- Functional Fit, Usability, Performance, Security, Maintainability, Testability, Flexibility, interoperability, and so on the list goes on unending with several abilities.
Most of the times, Quality measurement goes with a standard template developed by some quality champion with in the organization. There will be a lot of thumb rules applied. So, projects mechanically collect the data and fill in the spreadsheets required by the Quality people.
No one really cares about the figures as long as the customer is happy. When customer is unhappy there will be an additional audit done and few NCRs (non conformance reports) logged against the project. The show continues.
Quality Measurement should be done religiously to improve the quality of the project - Not just to fulfill the requirements of the Quality department and filling up spreadsheets just for the sake of it.
It starts right at the planning stage when identifying work items and the quality goals. Be realistic when doing this part of the planning to achieve the best results for both the service provider and the customer.
Time, Cost and Quality is the well known triple constraint. How to workout this is taught and practiced by several project management methodologies like PMP and Prince2 etc.,
It is a general feeling that Quality is all about Measurement, defining the measure, collecting the data, plotting the data against an upper and lower bound and analyzing the results when there are cases of data falling outside the tolerance limits.
What is wrong with this? Nothing. But the key lies in defining the measure. There are several factors of the quality :- Functional Fit, Usability, Performance, Security, Maintainability, Testability, Flexibility, interoperability, and so on the list goes on unending with several abilities.
Most of the times, Quality measurement goes with a standard template developed by some quality champion with in the organization. There will be a lot of thumb rules applied. So, projects mechanically collect the data and fill in the spreadsheets required by the Quality people.
No one really cares about the figures as long as the customer is happy. When customer is unhappy there will be an additional audit done and few NCRs (non conformance reports) logged against the project. The show continues.
Quality Measurement should be done religiously to improve the quality of the project - Not just to fulfill the requirements of the Quality department and filling up spreadsheets just for the sake of it.
It starts right at the planning stage when identifying work items and the quality goals. Be realistic when doing this part of the planning to achieve the best results for both the service provider and the customer.
Monday, October 1, 2007
Patterns
Patterns - well known problem - solution pairs. They are good to solve the common problems - only if the problem exists.
The designers tend to get carried away by the patterns and apply different patterns to the general templates only to complicate the design. Sometimes over applying the pattern results in performance and maintainability issues to the solution rather than solving the problem.
So, I know the common solution so I will create the common problem.
Even in solutioning a consultant tend to have certain patterns and provides solutions using those patterns. This should be only applied after careful thought process, considering all other parameters of solution being same.
Each business situation will have its own Uniqueness - So, be careful when applying the past knowledge (pattern) while providing solutions.
The designers tend to get carried away by the patterns and apply different patterns to the general templates only to complicate the design. Sometimes over applying the pattern results in performance and maintainability issues to the solution rather than solving the problem.
So, I know the common solution so I will create the common problem.
Even in solutioning a consultant tend to have certain patterns and provides solutions using those patterns. This should be only applied after careful thought process, considering all other parameters of solution being same.
Each business situation will have its own Uniqueness - So, be careful when applying the past knowledge (pattern) while providing solutions.
Subscribe to:
Posts (Atom)
