Sunday, October 10, 2010
Entering 888th work week
I have completed my 17 years working in Information Technology industry. In past 17 years I have realized the essence of above statement by Einstein.
Most of the times, people can't explain things simply. The problem IT industry is seeing today is the focus on "Information" has been lost completely and the whole industry is running behind "Technology"!
I wish all the best to the industry on this special day of 10/10/10 at 10AM IST.
Friday, October 8, 2010
Review of "Quality Reviews"
Review is considered to be one of the important methods of Quality Assurance (QA) of software systems.
Review in software product / development:
Now, let us take a "review" of the review process in software product.
1. A software deliverable is architected as per the business requirement. The software architecture is reviewed by a reviewer to assure that architecture meets the functional and non-functional (scalability/performance/interoperability etc.,) requirements of the business.
2. Software deliverable-s are designed as per the architecture. The design is reviewed by a reviewer again to assure the design meets the architecture.
3. The design is implemented into software program-s (code) and the code is reviewed with reference to the design.
4. Each unit of code is also tested by the developer or an independent tester to make sure code has met the design specifications!
5. All the different units of software are integrated to realize the overall architecture of the software product. The integrated product is tested for functional and non-functional requirements.
6. The product is released to the customer.
So, review is preventive measure of quality assurance that helps in avoiding injection of bugs where as testing is a reactive method of finding and fixing the bugs after the bugs are injected into the product.
Why software still have bugs?
In my opinion, the primary cause is lack of "self-review" of the work products delivered by the individuals. Each individual should be encouraged to develop a culture of reviewing the work-product (let it be the architecture, a design, a unit of code, a test spec, or anything else) before it goes out into the software development process chain. Once the organization is successful in this mechanism, the quality will automatically improve and the cost of QA will considerably reduce.
Note: QA managers need not worry... They still have their jobs safe!! Guess WHY?
Review in process outsourcing:
Looking from a different perspective of BPO or ITO scenarios, the quality of a process where development of a "deliverable unit" costs nearly same as the review of that unit, the review adds a 100% overhead and not a solution for the quality assurance. The philosophy should be driving the workforce to "Do it right first time"
within the execution of the process.
But, a Business Process Review and transformation to:
a. Identify possible scope of improvement
b. Evaluate the impact of change
c. implementing the proposed transformation in a smooth manner
will help the process to be more efficient with an improved productivity and customer satisfaction.
Conclusion:
a better process --> a better quality product.
Hence one should "review" the process first to improve the process efficiency and then focus on "review" of individual products produced by the process for a better quality.
Software development is also a process! Increased focus on a review of a wrong thing will not result in the improved quality.
Friday, October 1, 2010
Binding Energy of Software Systems
So, In software terms, this is the effort that has gone into the "integration" of the different system components into its final form of Business Application.
Traditionally the integration has followed different models in the software systems.
Silos: Multiple software components were developed on a specific technology / programming language like COBOL, C etc., and they are integrated vertically using the procedure calls and RPCs. It is difficult to integrate with a component that is outside the technology.
Star/Spaghetti i.e., point to point integration: In this method, different components of a business application talk to each other using the flat files, or other methods. As a need for integration arises, the necessary interface should be developed and deployed on both the interfacing components of the business application. Soon, we will have a very complex spaghetti created that is very difficult to maintain.
Hub and Spoke based EAI: To overcome the standardization problems of point to point interfaces, each component should talk a "common language" with a central HUB that mediates all the integration between the enterprise business systems in that common language. This technology has developed several standard adaptors for common business components.
Enterprise Service Bus (ESB): This is the most modern integration technique available today. The key difference is that the central HUB is replaced with a more open set of protocols that can integrate the business components beyond a single enterprise. It is more open and allows more loosely coupled, heterogeneous components to talk to each other by providing more sophisticated "translation" services to them.
So, it is important that sufficient "binding energy" is in the Enterprise Business System and the CORRECT structure/method is used for the integration to keep the software strong (for operations) and flexible (for tackling the changes) all the way through its lifetime.
For more information on binding energy (atomic physics) : http://en.wikipedia.org/wiki/Binding_energy
For more on Patterns in Business Service Choreography using ESB (IBM redbook): http://www.redbooks.ibm.com/redpapers/pdfs/redp3908.pdf
Monday, September 20, 2010
Condition Based Maintenance
This post aims at making CBM simple to understand.
Any "Asset" would need maintenance to give its optimal performance. Traditionally there are two strategies to manage the "Maintenance"
1. Wait till the equipment fails. As soon as it fails, fix the equipment/Asset. This is "reactive" maintenance. (Corrective Maintenance) The disadvantage is the unplanned downtime. You do not like the car to be broken down before the maintenance is done. is it not? But the advantage is we fix only what is required making it very "cost effective" mode of maintenance.
2. Maintain the Asset in a periodic schedule (Preventive Maintenance). Just like a car going for a service after every 5000 km run or after every 6 months. This will make the Asset perform without a breakdown, but the maintenance is expensive, we will change the oils etc., even when they can be used for further period. It amounts for more costs for maintenance.
So, there should be a more "smarter" approach for asset maintenance. Is it not? that is called a "predictive maintenance" or Condition Based Maintenance. Let us assume if we instrument the asset with more sensors they can exactly "measure" some key parameters, that can be used to compute the exact condition of the asset health and recognize certain "conditions" before they happen. Using this information, we can carryout the required "maintenance" of the asset. This approach will surely help reducing the maintenance costs and asset failures.
But, it adds additional instrumentation of sensors, data collection and processing the data to "intelligently" identify the conditions. When all this additional instrumentation, data collection and processing is considerably cheaper than the maintenance expenditure and it avoids a breakdown it is worth implementing it. Achieving this in a "smart" way is the key!
EAM with CBM will surely improve the operations of any "Asset Based" organization.
But when we look at the God's own creation, we see CBM everywhere... Macrocosmic System of the "World" and the microcosmic system of the "body" both implement the CBM to its nirvana. Both the systems sense the conditions, process them, present the conditions in a meaningful way and they also self HEAL the condition naturally which is the nirvana of "Asset Management"!!
Tuesday, September 14, 2010
My Technical White Paper on oracle.com
It is always a pleasure to see the customer happy after implementing the solution and makes a comment like this
“We use RUEI on technical administration to get information, how the application “feels” on customer side and for management point of view to get the information of SLA agreements in fact of guaranteeing a dedicated response time to our customers. We verify the SLA with RUEI KPIs which are implemented in a management dashboard.”
I randomly came across this paper on o.com and thought of sharing on my blog!
Monday, September 13, 2010
Enterprise Solution Architect
My teenage son sometimes wonders about what I do in the office to make my living....
Let me try to define the phrase "Solution Architecture". To do so, I got to first define the words that constitute the phrase in the correct context.
Solution :
A SYSTEM continuously experiences environmental change! Change in the system environment is a natural process. Sometimes the change is gradual and other times the change is sudden.
In any case a system (an enterprise itself is a SYSTEM!) has to have a built in mechanism to tackle the change.
When a "change" can't be handled by the system within its scope of operation, this change is called as a "problem" that needs a "Solution"
Architecture:
This is the tricky part of the phrase "Solution Architecture"!
Architecture is a discipline, a set of principles, methods, guidelines that can be used to create a "model" of a "system" from multiple view points of different stakeholders of the system. Once the model is constructed, it can be used to get a holistic view of the system by different stakeholders. It greatly helps the understanding of the problem and channelize the thought towards the challenge that is caused by the "problem"
Overall, the solution architecture is a discipline of finding the opportunities to improve the system gently to tackle the challenges posed by the environmental changes as well as making the system more "responsive" to future challenges by creating a multi-dimensional model of the system!
Enterprise Architecture
In the modern day every business organization is seen as a SYSTEM. So, Enterprise Architecture (EA) discipline is divided into four layers as
- Business, (what makes up the business - people, processes and tools; Its goal, structure and functioning)
- Data/Information,(what are the key data comes in and information needed for business functions both operational and strategic)
- Applications (How the data is captured, processed, stored and converted into the useful information and knowledge and presented to the right people at the right time!)
- Technology/Infrastructure Architectures. (What physical servers, network, storage components are required to run the applications within the budget meeting service levels)
With the "Cloud Computing Paradigm" is in, the business is seen as a loosely coupled services and each of the service can have three layered "clouding" in SaaS - Software as a Service, PaaS - Platform as a Service, and IaaS - Infrastructure as a Service. This cloud computing has changed the way we look at architecture in the Data/Information, Application and Technology/Infrastructure layers. An architect should consider the possible options of public (external supplier hosting the cloud), private (hosting a cloud within enterprise datacenter0 or hybrid (a combination of public and private) deployment models of the Cloud in these layers.
To make it simple, as an Enterprise Solution Architect, I draw different shapes and name them differently; I will connect those shapes to form a smooth looking flow between multiple layers of the enterprise and convince the key stakeholders that they have understood their current problem and different possible solutions to solve their problem. I will help them select the best solution option suitable for their budget and needs.....
It is FUN as I enjoy this!!
Sunday, September 5, 2010
Risk Management
In a trade where the producer with stock in hand selling the product directly to a consumer who is buying the product for cash, there is no risk involved.
But, when a producer is selling the product to a consumer on a monthly installment basis, producer evaluates and manages a possible "credit risk".
Similarly when a consumer is paying cash in advance for product that will be delivered later, the consumer is evaluating and managing the "operational risks" of the producer.
When the transaction do not involve either producer or consumer and dealt by the "traders" then the risk is on its peak! When a trader purely buys a commodity or an instrument for the sake of selling it for profit in future and not for his own consumption; then it calls in for a methodical evaluation and management of "RISK".
In the modern day markets, there are multiple layers of traders and exchanges that are involved, making the "risk management" highly complex. There are spot, index based, options and future contract type trades that happen in the financial and commodity sectors, which made "risk management" a key tradition in the trading business!
We have several mathematical simulation models and supporting IT solutions in the Trading Risk Management models today. Several organizations are in the process of implementing and modernizing the "risk management" solutions to make their business make better sense.
But there is a "risk" in choosing and implementing the right "risk management" solution itself. How to manage that risk? Sounding tricky??
Warren Buffet's quote on this goes like this: "Risk comes from not knowing what you're doing." Taking this simple guiding principle, one can tackle the risk easily!
The impact of risk can be surely reduced by right KNOWLEDGE of what is being done! If you do not have the right knowledge, transfer the risk to someone who has the right knowledge!
Personally, I have successfully transferred all the risks to the most knowledgeable one thereby became completely risk free!
Tuesday, August 17, 2010
Identity and Access management philosophy
IT always revolves around making necessary information accessible to the authorized person as and when required to carryout his/her duties and help taking crucial decisions.
So, this post is about "identity management" in the IT world.
Identity can be established by one or more of the three factors:
1. What the requester "knows" e.g., password
2. What the requester "has" e.g., a token that generates random numbers every few seconds
3. What the requester "is" e.g., finger print or retina scan
Before letting the requester access a resource of IT infrastructure, the first thing to be done is to establish the identity of the requesting entity. Once the identity of the requester is established, the second step is to make sure the requester has necessary access to the resource.
The requester may be authorized to
a. read or view the information resource
b. make some modification to the information resource
c. create a new information resource
d. delete one of the resource
Some times the access is dependent on the value of the resource (a bank officer can only approve a transaction of value less than "some max limit")
Separation of duties:
One requester can only create a table and maintain it, but will not be able to read the data from it.
so, the "access policy" could be very complex to define, maintain and enforce it on the IT infrastructure. One very evolved method is Role based access control - RBAC.
There are multiple vendors who provide the solutions around Identity and Access Management in the IT world.
But, interestingly this problem was ancient and in the Great Indian epic of Ramayana, Hanuman establishes his identity to Mother Seetha using a two factor model with a token and a pass phrase! I think we are only applying an ancient solution in a modern way with IAM solution stacks...
Some modern architectural patterns are on this RedPaper..... for those who are interested!
Monday, August 9, 2010
8035 days or 22 years!
The key point to make is my recent move from "Grid Control" to "Smart Grid" ...
Having worked for past 4 years with Oracle working with computing grid management software, I have moved over to IBM into consulting solutions around the power grids!
It is just few weeks into the new role, and currently focusing on the domestic market. A new role, in a new place with only thing common to my immediate past role is "GRID" but in the both contexts, this same word means completely different!
With a new learning experience everyday, "Grid" is going to keep me active for several more cycles...
Is it??
