The end to end IT infrastructure life cycle management includes the following:
1. Strategy
Covering the Portfolio & Financial Management
2. Design
Availability/Business Continuity/Capacity/Security Design
3. Transition
Change/Release/Configuration Management including provisioning and patching of technology stack
4. Operation
Incident/Problem Management involving the service monitoring and proactive management
5. Continual Improvement
Service Level Management and Improvement and Reporting
As per latest ITIL V3
Thursday, December 6, 2007
Wednesday, November 28, 2007
Testability - A key feature
When we define quality, there are several attributes of quality are talked about - Usability, functionality, performance, maintainability, interoperability, flexibility etc., several desired abilities of the given product. In a software product the testability is also an important feature.
The "Testability" is equally important measure for a software product as well as for the testing methodology.
When the product specification was drawn up, the testability requirements need to be given sufficient importance during the analysis & design phases. The early the testing requirements are drawn the better measure of quality can be done and finally a better product can be delivered.
There will be several phases of testing unit, system, integration, scalability, performance, load, disaster recovery etc., with different environments etc., during a software development project.
If the overall effort is not co-ordinated well the final product may not completely satisfy the customer!
The "Testability" is equally important measure for a software product as well as for the testing methodology.
When the product specification was drawn up, the testability requirements need to be given sufficient importance during the analysis & design phases. The early the testing requirements are drawn the better measure of quality can be done and finally a better product can be delivered.
There will be several phases of testing unit, system, integration, scalability, performance, load, disaster recovery etc., with different environments etc., during a software development project.
If the overall effort is not co-ordinated well the final product may not completely satisfy the customer!
Thursday, November 22, 2007
Business - IT alignment
Business of an enterprise will normally need certain capabilities from their Information Technology resources. Different users at different levels of the enterprise would need access to right information at the right time. The customers and suppliers should be able to get the access to the right information as and when required. The information should accurately captured, stored and presented to the users as necessary.
In this process, IT resources are built in form of hardware - storage and processors, Network infrastructure. Software - OS, Databases, OLTP apps, BI tools.
Historically all this IT resources were procured, configured and maintained by the enterprises as a centralized department, then they started outsourcing certain functions. of late there are several pay per use solutions, hosting solutions and software as service solutions are coming up.
Coming to the topic of Business - IT alignment: At what level the alignment should start? CEO, COO, CIO/CTO should have this alignment done on a regular basis cascading the impact down to enterprise and closing the loop by getting the feedback from all levels.
It is a process (continuous) rather than a project (one time activity)!!!
In this process, IT resources are built in form of hardware - storage and processors, Network infrastructure. Software - OS, Databases, OLTP apps, BI tools.
Historically all this IT resources were procured, configured and maintained by the enterprises as a centralized department, then they started outsourcing certain functions. of late there are several pay per use solutions, hosting solutions and software as service solutions are coming up.
Coming to the topic of Business - IT alignment: At what level the alignment should start? CEO, COO, CIO/CTO should have this alignment done on a regular basis cascading the impact down to enterprise and closing the loop by getting the feedback from all levels.
It is a process (continuous) rather than a project (one time activity)!!!
Wednesday, November 7, 2007
Virtualization and Grid Computing
1. Virtualization: Using hardware resources across virtual hosts making the hardware utilization better across a data center. Also provide quick turnaround times to build new hosts for the development and test infrastructures.
2. Grid Computing: Use low cost hardware resources to accomplish production tasks with high redundancy and performance.
"1" is actually partitioning a physical host into multiple virtual hosts and use the physical resources more effectively where as "2" is to combine multiple smaller physical hosts behave as if it were a big single host.
These different solutions are best utilized to solve different problems. All these multiple technology options when used in a correct manner surely reduce the cost and improve the utilization of the data center resources.
2. Grid Computing: Use low cost hardware resources to accomplish production tasks with high redundancy and performance.
"1" is actually partitioning a physical host into multiple virtual hosts and use the physical resources more effectively where as "2" is to combine multiple smaller physical hosts behave as if it were a big single host.
These different solutions are best utilized to solve different problems. All these multiple technology options when used in a correct manner surely reduce the cost and improve the utilization of the data center resources.
Friday, October 26, 2007
Best of Breed
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.
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 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.
Friday, September 28, 2007
Flexibility & Performance
There are known pairs of opposites called architectural considerations. If there is all the money and time in the world given to a project, then the final result of the project (= product ) will not have any bugs, will be highly flexible and highly performant.
But, the reality is - "there are only limited resources - time and cost" available for building the solution. The "QUALITY" is dependent on the available resources.
It is very important to understand which of the contrasting qualities are important for the product. If the solution should be highly flexible it may not be performing at the highest level. To add flexibility one should introduce additional processing.
A real solutioning process is to strike the right balance between the various demands of the expected solution.
But, the reality is - "there are only limited resources - time and cost" available for building the solution. The "QUALITY" is dependent on the available resources.
It is very important to understand which of the contrasting qualities are important for the product. If the solution should be highly flexible it may not be performing at the highest level. To add flexibility one should introduce additional processing.
A real solutioning process is to strike the right balance between the various demands of the expected solution.
Tuesday, September 25, 2007
Technology Driven Change
Sometimes, customer want to get on to the bandwagon too quickly and want to use a new technology with a huge percieved benifit. There is no real need from a business for a change, the project involves creating a completely new technology stack involving comparitively new technology. (which may not be fully mature and undergoing a lot of instability)
It is always good to experimant with a small proof of concept, understand the impacts of new technology after thouroughly evaluating the benifits. The justification and the business case should include tangible and measurable benifts and there should be full involvement from the business in such cases.
If a programme gets approved without complete buy in from the business it suffers from lack of commitment from the business and eventuall it fails to deliver the percieved benifits.
Ideally any change should be driven by the Business -> technology. What about the new technology completely changes a specific business? That is where the evaluation of new technology carefully fronted by the technologists and business specialists called "STRATEGY" team comes for rescue. Still the change is driven by business not by the technology.
Thumb rule ----- Business Change (whatever the reason including the technology advancement ) should lead Technology Change
It is always good to experimant with a small proof of concept, understand the impacts of new technology after thouroughly evaluating the benifits. The justification and the business case should include tangible and measurable benifts and there should be full involvement from the business in such cases.
If a programme gets approved without complete buy in from the business it suffers from lack of commitment from the business and eventuall it fails to deliver the percieved benifits.
Ideally any change should be driven by the Business -> technology. What about the new technology completely changes a specific business? That is where the evaluation of new technology carefully fronted by the technologists and business specialists called "STRATEGY" team comes for rescue. Still the change is driven by business not by the technology.
Thumb rule ----- Business Change (whatever the reason including the technology advancement ) should lead Technology Change
Friday, September 21, 2007
The Unix command I like most
The UNIX shell command "who am i" is what I like most. When I type it on a shell prompt I get something like
PrasadChitta pts/57 Jul 23 21:36 (hostname.domainname.com)
Why is this important on a blog named techno functional consulting? Some times when on a consulting assignment one should remember this command.
A consultant should help achieve the goal of the project without any bias. Sometimes the consultants cause more confusion especially during the technology selection, vendor selection phases. There is no fixed rule that only one vendor or technology is the best suitable for a given problem ---
All the business problems are more are less similar - to over simplify - "read, insert, update or delete data from/to the storage".
There are a lot of environmental, operational, security, performance, cost, ... type of non functional considerations which will drive the selection process along with the functional requirements of a given situation. It is really difficult to get an "independent consultant".
That is where I use my favorite UNIX command "who am i" to help me play the correct role as an independent consultant when on an assignment.
Other than my consulting career, I search for the answer for the same question spiritually - that is another reason for the liking of this command.
PrasadChitta pts/57 Jul 23 21:36 (hostname.domainname.com)
Why is this important on a blog named techno functional consulting? Some times when on a consulting assignment one should remember this command.
A consultant should help achieve the goal of the project without any bias. Sometimes the consultants cause more confusion especially during the technology selection, vendor selection phases. There is no fixed rule that only one vendor or technology is the best suitable for a given problem ---
All the business problems are more are less similar - to over simplify - "read, insert, update or delete data from/to the storage".
There are a lot of environmental, operational, security, performance, cost, ... type of non functional considerations which will drive the selection process along with the functional requirements of a given situation. It is really difficult to get an "independent consultant".
That is where I use my favorite UNIX command "who am i" to help me play the correct role as an independent consultant when on an assignment.
Other than my consulting career, I search for the answer for the same question spiritually - that is another reason for the liking of this command.
Tuesday, September 18, 2007
Simple looking Complex problem
Approximately a decade back, after spending nearly two years on an optimization problem, I have ended up with the following problem. This is a variation of combination algorithm.
Assume that there are 'm' groups with each group will have 'nelem(i)' elements where i = 1 to m and nelem(i) > 0 (zero)
The problem is to find out all the possible combinations picking exactly one element from each group. [each element in a group is distinct and imagine it is numbered 1, 2, ... nelem(i)]
It looks very simple in the first look but takes time to solve this problem. If you are a programmer try to solve it for yourself. Just try to write an algorithm for this and you will realize the complexity of this problem.
So, there are certain things look very simple when you first see them. Only when coming to implement the solution the real complexity will appear.
Example output 1:
Number of Groups : 4
Number of Elements in Group 1 : 3
Number of Elements in Group 2 : 2
Number of Elements in Group 3 : 1
Number of Elements in Group 4 : 2
G1:1 G2:1 G3:1 G4:1
G1:1 G2:1 G3:1 G4:2
G1:1 G2:2 G3:1 G4:1
G1:1 G2:2 G3:1 G4:2
G1:2 G2:1 G3:1 G4:1
G1:2 G2:1 G3:1 G4:2
G1:2 G2:2 G3:1 G4:1
G1:2 G2:2 G3:1 G4:2
G1:3 G2:1 G3:1 G4:1
G1:3 G2:1 G3:1 G4:2
G1:3 G2:2 G3:1 G4:1
G1:3 G2:2 G3:1 G4:2
Example Output 2:
Number of Groups : 3
Number of Elements in Group 1 : 5
Number of Elements in Group 2 : 3
Number of Elements in Group 3 : 2
G1:1 G2:1 G3:1
G1:1 G2:1 G3:2
G1:1 G2:2 G3:1
G1:1 G2:2 G3:2
G1:1 G2:3 G3:1
G1:1 G2:3 G3:2
G1:2 G2:1 G3:1
G1:2 G2:1 G3:2
G1:2 G2:2 G3:1
G1:2 G2:2 G3:2
G1:2 G2:3 G3:1
G1:2 G2:3 G3:2
G1:3 G2:1 G3:1
G1:3 G2:1 G3:2
G1:3 G2:2 G3:1
G1:3 G2:2 G3:2
G1:3 G2:3 G3:1
G1:3 G2:3 G3:2
G1:4 G2:1 G3:1
G1:4 G2:1 G3:2
G1:4 G2:2 G3:1
G1:4 G2:2 G3:2
G1:4 G2:3 G3:1
G1:4 G2:3 G3:2
G1:5 G2:1 G3:1
G1:5 G2:1 G3:2
G1:5 G2:2 G3:1
G1:5 G2:2 G3:2
G1:5 G2:3 G3:1
G1:5 G2:3 G3:2
I have posed this problem to several programming experts. Still I did not get a better solution yet!
Assume that there are 'm' groups with each group will have 'nelem(i)' elements where i = 1 to m and nelem(i) > 0 (zero)
The problem is to find out all the possible combinations picking exactly one element from each group. [each element in a group is distinct and imagine it is numbered 1, 2, ... nelem(i)]
It looks very simple in the first look but takes time to solve this problem. If you are a programmer try to solve it for yourself. Just try to write an algorithm for this and you will realize the complexity of this problem.
So, there are certain things look very simple when you first see them. Only when coming to implement the solution the real complexity will appear.
Example output 1:
Number of Groups : 4
Number of Elements in Group 1 : 3
Number of Elements in Group 2 : 2
Number of Elements in Group 3 : 1
Number of Elements in Group 4 : 2
G1:1 G2:1 G3:1 G4:1
G1:1 G2:1 G3:1 G4:2
G1:1 G2:2 G3:1 G4:1
G1:1 G2:2 G3:1 G4:2
G1:2 G2:1 G3:1 G4:1
G1:2 G2:1 G3:1 G4:2
G1:2 G2:2 G3:1 G4:1
G1:2 G2:2 G3:1 G4:2
G1:3 G2:1 G3:1 G4:1
G1:3 G2:1 G3:1 G4:2
G1:3 G2:2 G3:1 G4:1
G1:3 G2:2 G3:1 G4:2
Example Output 2:
Number of Groups : 3
Number of Elements in Group 1 : 5
Number of Elements in Group 2 : 3
Number of Elements in Group 3 : 2
G1:1 G2:1 G3:1
G1:1 G2:1 G3:2
G1:1 G2:2 G3:1
G1:1 G2:2 G3:2
G1:1 G2:3 G3:1
G1:1 G2:3 G3:2
G1:2 G2:1 G3:1
G1:2 G2:1 G3:2
G1:2 G2:2 G3:1
G1:2 G2:2 G3:2
G1:2 G2:3 G3:1
G1:2 G2:3 G3:2
G1:3 G2:1 G3:1
G1:3 G2:1 G3:2
G1:3 G2:2 G3:1
G1:3 G2:2 G3:2
G1:3 G2:3 G3:1
G1:3 G2:3 G3:2
G1:4 G2:1 G3:1
G1:4 G2:1 G3:2
G1:4 G2:2 G3:1
G1:4 G2:2 G3:2
G1:4 G2:3 G3:1
G1:4 G2:3 G3:2
G1:5 G2:1 G3:1
G1:5 G2:1 G3:2
G1:5 G2:2 G3:1
G1:5 G2:2 G3:2
G1:5 G2:3 G3:1
G1:5 G2:3 G3:2
I have posed this problem to several programming experts. Still I did not get a better solution yet!
Friday, September 14, 2007
Simple vs Complex
"There is no simple and correct solution to a complex problem." - but there are always multiple simple and wrong solutions to a complex problem.
Multiple simple (wrong) solutions make up a complex mess over a period of time and actually make the final solution more complicated to work with. Eventually it will end up in multiple technologies, data duplication, lot of backed scripts and unknown programs running to accomplish the task to some extent. Manual work - not to say several spreadsheets and personal databases on the end user computers performing a business critical report generation for company's CEO after getting the data from a high end data warehouse using a best possible OLAP tools.
So, giving a through thought about the solution architecture with a strategic perspective is very essential to a consultant.
Multiple simple (wrong) solutions make up a complex mess over a period of time and actually make the final solution more complicated to work with. Eventually it will end up in multiple technologies, data duplication, lot of backed scripts and unknown programs running to accomplish the task to some extent. Manual work - not to say several spreadsheets and personal databases on the end user computers performing a business critical report generation for company's CEO after getting the data from a high end data warehouse using a best possible OLAP tools.
So, giving a through thought about the solution architecture with a strategic perspective is very essential to a consultant.
Thursday, September 13, 2007
Tactical Trap
People fall into this trap generally after the confusion. Result is a Spaghetti. What do I mean by the tactical spaghetti architecture created by so called "tactical consultants"?
Tactical = Quick and Dirty
For a confusing change people will quickly find a tactical solution making the overall information systems more and more confusing.
Reasons for the tactical solutions are many, but they can be grouped into
a. time and cost constraints and
b. lack of strategic view pointEventually these tactical solutions will run years in an organization and become critical applications without proper documentation.
Confusion and Consulting
Consulting generally starts with confusion. Some call it as
gap between the requirement and what is available, some call it as a scalability issue, technology advancement, sometimes business change, merger or de-merger, or even sometimes as regulatory requirement or as auditing or safety measure or statutory change ---> In a nutshell CHANGE.
Change causes confusion in choosing the future course of action.
gap between the requirement and what is available, some call it as a scalability issue, technology advancement, sometimes business change, merger or de-merger, or even sometimes as regulatory requirement or as auditing or safety measure or statutory change ---> In a nutshell CHANGE.
Change causes confusion in choosing the future course of action.
Wednesday, September 12, 2007
Why this blog?
According to me CONSULTING is one art and science. There are no sub-divisions in it. Today in the IT world there are technical consultants, functional consultants, business consultants, architectural consultants and this list goes on and on....
After looking at the Information Technology in research, banking, insurance, Public utility transportation, distribution, metering, manufacturing and government sectors closely being a part of the consulting community, I want to share some of my thoughts on technology areas like c, Unix, CASE tools, Mainframe, Thick Client, Thin Client, databases, file organisations, expert systems, business intelligence, scheduling and optimization, GIS, Asset Management, Work management, ERP and Back office, CRM and front office, Field Force automation, Open Systems, Scripting, Automation, EAI, Standards, Frameworks, Compliance, 6sigma, Enterprise Architecture transformation programmes, business change management, programme management, ITIL, Systems management, benchmarking, configuration management, business intelligence, OLTP and OLAP, data mining, warehousing, ETL, OOAD, UML and Modelling, XML, SOAP, Web services and few more...
After looking at the Information Technology in research, banking, insurance, Public utility transportation, distribution, metering, manufacturing and government sectors closely being a part of the consulting community, I want to share some of my thoughts on technology areas like c, Unix, CASE tools, Mainframe, Thick Client, Thin Client, databases, file organisations, expert systems, business intelligence, scheduling and optimization, GIS, Asset Management, Work management, ERP and Back office, CRM and front office, Field Force automation, Open Systems, Scripting, Automation, EAI, Standards, Frameworks, Compliance, 6sigma, Enterprise Architecture transformation programmes, business change management, programme management, ITIL, Systems management, benchmarking, configuration management, business intelligence, OLTP and OLAP, data mining, warehousing, ETL, OOAD, UML and Modelling, XML, SOAP, Web services and few more...
Subscribe to:
Posts (Atom)
