Before I write a blog post, I spend some time on understanding the concept from a geeks perspective. The intention is to simplify the concept and make it easier to understand / imagine (abstracting hi-tech lingo).
Let’s talk about SaaS… SaaS stands for Software as Service, which is becoming very popular trend in the software industry. Let’s try to understand how it’s different from have we have now (& had in past).
Hotmail.com, one of the most used online email software that is delivered as a service to end users. Now what is wrong in the hotmail that stops me tagging it as SaaS ? Salesforce.com is offering in-the-cloud version of CRM software that can be accessed over Internet. Both salesforce.com and hotmail doesn’t require any installation at user side and serves multiple users from single instance.
Salesforce delivers CRM, a line of business application and changes $59.00 per user per month, with no upfront cost. On the other side hotmail is a generic free email service available to internet users. The nature of the service is what differentiates a SaaS applications with other internet based (consumer) applications. A line of business SaaS application is a paid solution that addresses a business problem and requires a customized delivery channel.
When you want to get a line-of-business (LOB) application like an ERP; Currently, you will have to check for an ERP vendor, finalize the best fit solution, buy the hardware to install and plan for maintenance and customization. In the SaaS world the software is paid as it is consumed and the end user required no software or infrastructure to buy, install and maintain.
Though the concept sounds very exciting, there are lot of challenges that needs to be addressed for achieving the SaaS delivery model. There is a complete lifecycle considerations starting from Discovery, SLA, Security, Performance, Deployment etc.; which is beyond the scope of this topic; I’ll only mention the key considerations.
On the top is the multitenancy concept. This is like you have tenants in different apartments of a housing complex, sharing some common facilities (Beside having their private amenities). In SaaS, each tenant is the customer/ consumer of the hosted service instance. The multitenant-efficient SaaS offering supports a data model that allows sharing of the database and resources, while protecting data access to each of the individual tenants.
Next thing to consider is the ability to provide customized service based on the tenant while running a single instance of the service. This can be achieved by using metadata that describes the attributes of a tenant and map it with service. In other words, the behavior of service is defined by the metadata associated with each tenant. The level/ effort of customization required for each tenant is reduced by having the metadata.
Monday, March 17, 2008
Monday, March 3, 2008
Design for Upgrade
While this blog is more inclined towards the Agile software implementation, one of the incident happened last month has forced me to pen in a few thoughts on software architecture. We developed an application with Microsoft Office SharePoint and InfoPath. The development started a year back with Office 2003 and now it’s migrated to MOSS 2007. The application has been simply architected, keeping in mind the customer requirements. As mentioned in one of my previous post, the “tale of never ending requirements” hit us in the middle of migration. A new product release always carries additional/ improved features for addressing business problems. During the migration, it makes sense to evaluate new features and analyze the possibility of leveraging them for addressing business problems (in better way). Having said this, the solution architecture must support the up-gradation scenario with reasonable amount of time and effort.
Design decisions while architecting a software solution are derived from various sources like availability of resources, customer needs and preferences, business domain etc. However, the basics remains unchallenged for every implementation scenario. One of such fundamental is explained in this great quote from “Software Architecture in Practice, Bass, Clements, Kazman”
"Architects make design decisions because of the downstream effects they will have on the system(s) they are building and these effects are known and predictable. If they were not, the process of crafting an architecture would be no better than throwing dice. "
No architecture can be perfect, in-fact you do a tradeoff between software systems attributes to come with the best possible solution for specific business requirements. Thinking of an architecture generally brings into mind the concepts of layers and tiers (layers are logical separation of components while tiers are physical). Each layer will add an additional message call which will hit the response time. Then why architects still model the system in separate layers and takes the performance hit? The answer is “to make complex things simple”. More complex the system requirement is, more are the number of layers that are generally included in the solution architecture.
Coming back to our scenario, how would an architecture can support the technology up-gradation process? I believe there can not be a complete answer to this; unless you understand the vision of the technology/ product company, it’s difficult to handle this 100% with architecture. However, there are some basic principles that remains unchallenged. XML functional calls, loosely coupled layers, different tiers for application and database etc. are few checks to handle the situation .
Design decisions while architecting a software solution are derived from various sources like availability of resources, customer needs and preferences, business domain etc. However, the basics remains unchallenged for every implementation scenario. One of such fundamental is explained in this great quote from “Software Architecture in Practice, Bass, Clements, Kazman”
"Architects make design decisions because of the downstream effects they will have on the system(s) they are building and these effects are known and predictable. If they were not, the process of crafting an architecture would be no better than throwing dice. "
No architecture can be perfect, in-fact you do a tradeoff between software systems attributes to come with the best possible solution for specific business requirements. Thinking of an architecture generally brings into mind the concepts of layers and tiers (layers are logical separation of components while tiers are physical). Each layer will add an additional message call which will hit the response time. Then why architects still model the system in separate layers and takes the performance hit? The answer is “to make complex things simple”. More complex the system requirement is, more are the number of layers that are generally included in the solution architecture.
Coming back to our scenario, how would an architecture can support the technology up-gradation process? I believe there can not be a complete answer to this; unless you understand the vision of the technology/ product company, it’s difficult to handle this 100% with architecture. However, there are some basic principles that remains unchallenged. XML functional calls, loosely coupled layers, different tiers for application and database etc. are few checks to handle the situation .
One important point to consider: If requirements are simple then it’s not recommended to take the performance hit by including layers. Trying to over simplify the system will make it complex 
Thursday, August 16, 2007
Clear Business Goals
This post is in continuation of project success series। We will discuss the point number 3 i.e. clear scope and business objectives.
Any software project, based on it’s outcome falls into 3 categories। 1) Successful, 2) Failed & 3) Hanged project. Hanged projects are the most (in)famous and interesting ones. The beauty of hanged project is the fact that they get’s accepted by customer but still it’s of no use to end user.
Software is developed to meet some business goals and if the goals are not clear and measurable, you will get a hanged software. I would like to mention here the key difference between failed and hanged software; Failed software doesn’t meets software requirements (specifications) and is never accepted by customer, while hanged one meets documented requirements but doesn’t helps reaching business/individual goals.
Individuals either opt to use the software or they are forced to do so; Individual goals makes sense, only when they are inline with business goals of an organization they work for। Complexity begins when individuals start considering these goals as the solution of their functional problems. So we have business goals and business problems and the difference between them is the ability to measure. For example, the “customer wants to increase the production” is a business problem. This business goal is that “customer wants to increase the production by 50%”.
Arnold H. Glasgow says: “In life, as in football, you won't go far unless you know where the goalposts are.” During the software development, it’s important to check and measure the progress towards business goals। The iterative model of agile development helps in this context. I remember the control theory of Feedback Control Systems (taught in B.E, Elec. & Telecom) which defines “feedback” as a process whereby some proportion of the output signal of a system is passed (fed back) to the input. This is often used to control the dynamic behavior of the system. Example is the missile guidance system which measure the position at regular intervals and send it back to control device. The theory fits well in agile development scenario where we take user feedback at regular intervals and adjust the output accordingly.
Coming back to hanged projects; they are derived by specifications that states business problems (most of the times) and not the measurable goals. Though these goals are defined from customer, the project analyst must help transforming business problem statements to measurable goals. This way I believe a customer will have the value for money she has spent to build a software. For us, the software is successful when it’s used by end users and not just delivered and signed off.
Any software project, based on it’s outcome falls into 3 categories। 1) Successful, 2) Failed & 3) Hanged project. Hanged projects are the most (in)famous and interesting ones. The beauty of hanged project is the fact that they get’s accepted by customer but still it’s of no use to end user.
Software is developed to meet some business goals and if the goals are not clear and measurable, you will get a hanged software. I would like to mention here the key difference between failed and hanged software; Failed software doesn’t meets software requirements (specifications) and is never accepted by customer, while hanged one meets documented requirements but doesn’t helps reaching business/individual goals.
Individuals either opt to use the software or they are forced to do so; Individual goals makes sense, only when they are inline with business goals of an organization they work for। Complexity begins when individuals start considering these goals as the solution of their functional problems. So we have business goals and business problems and the difference between them is the ability to measure. For example, the “customer wants to increase the production” is a business problem. This business goal is that “customer wants to increase the production by 50%”.
Arnold H. Glasgow says: “In life, as in football, you won't go far unless you know where the goalposts are.” During the software development, it’s important to check and measure the progress towards business goals। The iterative model of agile development helps in this context. I remember the control theory of Feedback Control Systems (taught in B.E, Elec. & Telecom) which defines “feedback” as a process whereby some proportion of the output signal of a system is passed (fed back) to the input. This is often used to control the dynamic behavior of the system. Example is the missile guidance system which measure the position at regular intervals and send it back to control device. The theory fits well in agile development scenario where we take user feedback at regular intervals and adjust the output accordingly.
Coming back to hanged projects; they are derived by specifications that states business problems (most of the times) and not the measurable goals. Though these goals are defined from customer, the project analyst must help transforming business problem statements to measurable goals. This way I believe a customer will have the value for money she has spent to build a software. For us, the software is successful when it’s used by end users and not just delivered and signed off.
Tuesday, July 24, 2007
Agile Leadership
The chances for software to succeed are much higher if you have a leader (not Manager) working in it. The difference between a Leader and Manager is well explained by Warren Bennis: “Management is getting people to do what needs to be done. Leadership is getting people to want to do what needs to be done.”
What distinguishes leaders from managers?
from a possible list of 20 values:
The results are shown in figure below
Honesty on the top !
What distinguishes leaders from managers?
- Leaders are interested in direction, vision, goals, objectives, effectiveness and purpose. Managers are interested in efficiency, both day-to-day and short-run.
- Managers administer while leaders innovate.
- Managers focus on systems and structure; leaders focus on people.
- Managers rely on control; leaders inspire trust.
- Managers have their eye on the bottom line; leaders have their eye on the horizon.
The best leaders care about both the small and big pictures. They sweat the details -- but they also have the ability to make people feel valued ... to inspire and energize them, to nurture their creativity and to encourage them to take risks and learn from their mistakes. The top qualities of Leaders are:
- Character: Should be honest and must understand the gravity of words; That’s the key quality of a leader.
from a possible list of 20 values:
The results are shown in figure below
Honesty on the top !
- Technical competence: Technology and domain expertise. Ability to help and solve project issues.
- Clear Vision: Leaders know their goals and way to reach their in time.
- Team handling and Communication: The ability to communicate, motivate, delegate and ability to identify and cultivate talent in team members.
- Decision Making: Ability to take quick and right decisions
Tuesday, July 10, 2007
Incredible 4 years...
Today (July 10, 2007), I have completed 4 years in Trisoft Systems. This has been my first job change, RMSI being the first employer (3.5 years). It was a tough decision for me to choose between TCS and Trisoft. I’m glad I’ve taken the right one. I've been fortunate enough to have had the opportunity to work upon quality solutions with latest technologies here in Trisoft.
Working as a Solutions Architect now, I started here as BizTalk developer. My first project was based on cXML integration that was a success. Another important milestone was Catapult, we did this project for Microsoft Redmond. The product was appreciated and accepted (in time) and is now being used in various departments in Microsoft Redmond.
This has been an incredible journey where I've witnessed a number software renovations and my perspective of software has been improved a lot…from coding to usability, job completion to profitability and documentation to agility.
We’ve moved to a much bigger office in Noida (India), more determined to grow fast in coming years. You never know where I would be next year…but so far it’s so good and I love being here.
Working as a Solutions Architect now, I started here as BizTalk developer. My first project was based on cXML integration that was a success. Another important milestone was Catapult, we did this project for Microsoft Redmond. The product was appreciated and accepted (in time) and is now being used in various departments in Microsoft Redmond.
This has been an incredible journey where I've witnessed a number software renovations and my perspective of software has been improved a lot…from coding to usability, job completion to profitability and documentation to agility.
We’ve moved to a much bigger office in Noida (India), more determined to grow fast in coming years. You never know where I would be next year…but so far it’s so good and I love being here.
Glossary
Following are the key-words used extensivly in Agile world; you must be aware.
SCRUM
http://en.wikipedia.org/wiki/Scrum_%28development%29
Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototypes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.
Pair programming
Pair programming requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example.
The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.
Test-Driven Development (TDD)
http://en.wikipedia.org/wiki/Test_driven_development
Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development gives rapid feedback. The technique began to receive publicity in the early 2000s as an aspect of Extreme Programming, but more recently is creating more general interest in its own right.
Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.
Along with other techniques, the concept can also be applied to the improvement and removal of software defects from legacy code that was not developed in this way.
Feature Driven Development
http://en.wikipedia.org/wiki/Feature_Driven_Development
Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
Aspect-oriented programming
http://en.wikipedia.org/wiki/Aspect_Oriented_Programming
In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they cut across many modules in a program.
Adaptive Software Development
http://en.wikipedia.org/wiki/Adaptive_Software_Development
Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.
SCRUM
http://en.wikipedia.org/wiki/Scrum_%28development%29
Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototypes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.
Pair programming
Pair programming requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example.
The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.
Test-Driven Development (TDD)
http://en.wikipedia.org/wiki/Test_driven_development
Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development gives rapid feedback. The technique began to receive publicity in the early 2000s as an aspect of Extreme Programming, but more recently is creating more general interest in its own right.
Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.
Along with other techniques, the concept can also be applied to the improvement and removal of software defects from legacy code that was not developed in this way.
Feature Driven Development
http://en.wikipedia.org/wiki/Feature_Driven_Development
Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
Aspect-oriented programming
http://en.wikipedia.org/wiki/Aspect_Oriented_Programming
In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they cut across many modules in a program.
Adaptive Software Development
http://en.wikipedia.org/wiki/Adaptive_Software_Development
Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.
Monday, July 2, 2007
001 - Requirements Clarifications
In the Agile scenario, “Active stakeholder participation” throughout the project's lifecycle is described as one of the key success factor.
Though there are now doubts in above said point, the issue comes when you have stakeholders coming from a complete not IT background and it’s difficult for them to perceive the functional software. Sounds wacky? It’s common in South Asian countries, especially in the government departments. Such stakeholders are defined as: “End users who tells you what they really want on the day you give them what they've asked for”. Oops, I can know what I really want is only after seeing it.
Another thing I’ve faced is the “tale of never ending open requirements”. The project is kicked-off, teams have been finalized and stakeholders are identified for requirements clarifications. Users keeps on explaining about the functional requirements and issues they face with the existing system. In the middle of a requirement clarification (asked from software analyst) the user realizes that they’ve missed something…and here comes the brand new feature that turns out to be one of the key requirement of the software. Poor analyst, curse himself why the hell he asked for the damn clarification. Now by end of requirement phase, you’ll actually see little projects, trying to pop out of the additional (key) requirements.
These are the most common scenarios that are bound to happen during the requirement analysis phase (in this part of the word). The waterfall method by no means can address such challenges. Agile may be helpful is some situations, or al-least minimizes the risks.
Successful (Agile) Requirements Analysis Rules (for Nerds):
The #1 rule reminds me a quote I’ve seen on internet; called - Hoggarth's Law Reworded by MHR from Chris Hoggarth's email October 2006. It says “Attempts to get answers early in a project fail as there are many more wrong questions than right ones. Activity during the early stages should be dedicated to finding the correct questions. Once the correct questions have been identified correct answers will naturally fall out of subsequent work without grief or excitement and there will be understanding of what the project is meant to achieve.”
That’s the Rule #1: Prepare yourself first, do the homework before you start collecting requirements. Be sure of what you need to know from user (and what not).
Few months back, I was looking for a Air-conditioner and saw an advertisement of a electrical retail chain in the newspaper. They were selling the 1.5 ton A.C. for Rs. 13,000. It was the best deal I would get anywhere in summers so I went to this shop to place an order (Also took the newspaper for reference). I asked the sales guy that I am willing to buy the A.C. that costs 13,000 bucks. He replied that it’s the exchange offer and also the cost depends on the condition of the old A.C. I was surprised and showed him the newspaper where the exchange condition was nowhere mentioned. Now, this guy show me a small (microscopic) * in the advertisement that says “conditions apply”. I was shocked.
Rule #2: Be transparent and set the expectation right from day one. Don’t make too much assumptions in requirements.
The extension of Rule #2 is the rule of communication (language). Even if I had seen the “condition apply” (using magnifier), It was still difficult for me to understand what exactly does it means. The description of “conditions apply” must be given somewhere in the advertisement so that customer like me are not fooled around.
Develop a method to communicate with customers. Generally end users understand the user interface they are going to work with. Developing a UI prototype during the analysis would be of great help to end users and requirement analysts.
Rule #3: If it's is not on a paper it's never been said. Document each requirement clearly and maintain it’s relationship (traceability) in each phase.
Though there are now doubts in above said point, the issue comes when you have stakeholders coming from a complete not IT background and it’s difficult for them to perceive the functional software. Sounds wacky? It’s common in South Asian countries, especially in the government departments. Such stakeholders are defined as: “End users who tells you what they really want on the day you give them what they've asked for”. Oops, I can know what I really want is only after seeing it.
Another thing I’ve faced is the “tale of never ending open requirements”. The project is kicked-off, teams have been finalized and stakeholders are identified for requirements clarifications. Users keeps on explaining about the functional requirements and issues they face with the existing system. In the middle of a requirement clarification (asked from software analyst) the user realizes that they’ve missed something…and here comes the brand new feature that turns out to be one of the key requirement of the software. Poor analyst, curse himself why the hell he asked for the damn clarification. Now by end of requirement phase, you’ll actually see little projects, trying to pop out of the additional (key) requirements.
These are the most common scenarios that are bound to happen during the requirement analysis phase (in this part of the word). The waterfall method by no means can address such challenges. Agile may be helpful is some situations, or al-least minimizes the risks.
Successful (Agile) Requirements Analysis Rules (for Nerds):
The #1 rule reminds me a quote I’ve seen on internet; called - Hoggarth's Law Reworded by MHR from Chris Hoggarth's email October 2006. It says “Attempts to get answers early in a project fail as there are many more wrong questions than right ones. Activity during the early stages should be dedicated to finding the correct questions. Once the correct questions have been identified correct answers will naturally fall out of subsequent work without grief or excitement and there will be understanding of what the project is meant to achieve.”
That’s the Rule #1: Prepare yourself first, do the homework before you start collecting requirements. Be sure of what you need to know from user (and what not).
Few months back, I was looking for a Air-conditioner and saw an advertisement of a electrical retail chain in the newspaper. They were selling the 1.5 ton A.C. for Rs. 13,000. It was the best deal I would get anywhere in summers so I went to this shop to place an order (Also took the newspaper for reference). I asked the sales guy that I am willing to buy the A.C. that costs 13,000 bucks. He replied that it’s the exchange offer and also the cost depends on the condition of the old A.C. I was surprised and showed him the newspaper where the exchange condition was nowhere mentioned. Now, this guy show me a small (microscopic) * in the advertisement that says “conditions apply”. I was shocked.
Rule #2: Be transparent and set the expectation right from day one. Don’t make too much assumptions in requirements.
The extension of Rule #2 is the rule of communication (language). Even if I had seen the “condition apply” (using magnifier), It was still difficult for me to understand what exactly does it means. The description of “conditions apply” must be given somewhere in the advertisement so that customer like me are not fooled around.
Develop a method to communicate with customers. Generally end users understand the user interface they are going to work with. Developing a UI prototype during the analysis would be of great help to end users and requirement analysts.
Rule #3: If it's is not on a paper it's never been said. Document each requirement clearly and maintain it’s relationship (traceability) in each phase.
Subscribe to:
Posts (Atom)