Where lies the rhetoric?

Its amazing how many debates exist out there on what should be the 'right' reasons to start a business. There are so many theories around making-meaning, start-to-scale, greed-is-good, fast-company etc... The proportions of these principles contradicting each other is high. Equal number of empirical evidence exists to hold each of these theory on its own. The empirical evidence is mostly either in the form of demonstrated success stories and strong learning post-success or some are retro-rationale (as some call it). Are there enough based on the principles of failure in this culture and economic context? Are there enough which are from here (India) and not pre-canned?

There seems to be camps which discourage entrepreneurs-in-the-making (EIM) to first find the 'right' reason. If the reasons does not match the eye-of-the-beholder, they are quick to dismiss the EIM as a wannabe. There is also a term 'wannapreneur' for such dismissals. This seems to be applicable to the ideas as well, which gets discouraged cause the beholder has a strong opinion against it. Woah!!!

Funnily enough, these dismissals does not come from the Investment community. Most of the investors I have come across or heard of have mostly NEVER dismissed an entrepreneur based on the stated right or wrong reasons of the EIM. Generally, the Indian investment community (I have no interactions with others) is really a mature lot in understanding that there is no point being predictive and judgmental about the reasons. Also the investors confess that they have no way to even tell, as a matter of fact, if a given idea is a great scalable idea which will have huge returns or not. They have invested in ideas they think are awesome and failed (Ok, there are many reasons to fail. I agree), and have passed great ideas, where they did not have enough gut-feel (yes, that feeling in their stomach, not the brain) but later found that it was a big hit (Yes, there are equally many reasons to succeed).

Shouldn't people start business based on whatever reasons, principles, theories they believe-in is right? If the reasons are 'strong enough' to make a difference then it shall find the early-adopters, and if it is 'right enough', they will cross the chasm.

If the markets are the best course of correction, then, shouldn't we encourage every one who is willing to crossover, to do so, independent of their reasons? Shouldn't the eco-system have a healthy amount of failure for everyone to figure out the cost of failure (or a new path to succeed) for whatever the reasons may be?

I am of the belief that India lacks by huge margins (yet) in the number of startups per year (given the per-capita measure). Also, it is way-early to define reasons/principles of success which are context, economy and culture specific, as there are very few successful startups or number of exits (yet). The only way to increase this is to initially increase the size of funnel before applying any "qualifications" to the funnel. The qualifiers are not known yet. Even if (hypothetically) known, its not reason enough to stop the inflow of entrepreneur-energy-capital.

Entrepreneurial-Energy is a scarce resource. Kindly, encourage them to start...

What's the price?

I assisted a friend to purchase an assembled computer recently. There were 2 equally good vendors who offered the goods. One of the vendors was close to where we live while the other was about 30mins away. We approached the vendor nearby (In J P Nagar) and bargained on the price (common while purchasing assembled goods). The vendor nearby quoted INR 27,300/- for the same configuration while the other vendor was willing to go down to INR 27,150/. My friend settled to place an order with the vendor nearby as the price differential was only 0.5%.

Next we went to the nearby bookstore to browse some books. Friend decided to (after my rave reviews) pick the "The Black Swan" priced at INR 495/-. When we approached the desk, the gentleman behind the desk advised that a paper back version of the book discounted at 30%, is available in another store near Indiranagar (which is 40mins drive). We drove to Indiranagar to purchase the book.

Reflecting upon the events, the mental math made for NOT travelling an additional 30mins to save 0.5% off a purchase price, was offset (on the same day) by the mental math of saving a 30% off another product for which friend decided to drive 40mins.

In absolute terms, the savings in either case was INR 150/-. We clearly choose one versus the other.

Basic observation using this as an analogy for product pricing
(Eliminating the details around same-product versus like-to-like price comparisons)
Having a list-price of your product set to a ideal-ask price and then providing a relative discount to the list price has an edge compared to having a lower-list price and not offering discounts (while the absolute sale price being the same).

Behavioral Economics supports these observations and conclusions.

Worth pondering ?

What is fair ?

Life they say has a mind of its own. You may be the protagonist but not the hero. Dreams may not come true. Have tried and failed. Life is not fair.

But, Fairness has nothing to do with working on your dreams, even if you do not succeed. Standing up for who you are is one thing life cannot touch.

You know there is certain death. But will you stop living life ?

I am getting sore of hearing to excuses by well meaning people (whom i admire professionally) having amazing ideas and vibrant dreams which can change the world. Your If-only-this and but-only-that is harassing me in the arguments. Please stop. I can feel you dying a slow death. You are in pain. Is that fair ?

Show-up, walk the talk, live the dream. Get started. Now...

Welcome to the Jungle

And, if you need to learn the rules of the Jungle, you must live in the Jungle. Live, breathe and eat what the nature provides. You start with minimal resources anyway. The objective is to make good use of the resources provided by the eco-system. Learn the eco-system. The most important thing in the initial days is to get used to the eco-system. The new set of pathogens, different food, climate and creatures. It is these initial days that makes or breaks you. Once you weather the storm, you start getting acclimatized. The bacterias in your gut will change to accommodate digestion of different food. Your immune system will change.

Best of all, your so called intuition will change. You develop a Jungle sense of your own. You will be enamored with wild, rippling muscles and stamina required to participate in the eco-system. Your energy levels will be up. A brand new 'You'. It is this sense of feeling you must crave for...

The transition for some is painful. There is NO such thing as, "Ohhh, I shall go back to the city for some time and when I am feeling OK, I shall then return back to the Jungle...".

"Ohhh, I shall go back to the corporate life for some time and when the conditions are right i shall return back to start-up..."

I admit, its not this extreme (of course many die in the Jungle. But many more die in the city relatively... or live like deads...). I admit it does sound naive and yes your choices are always open. The metaphor is a different food for thought...

The Distribution of Intention

On one of the networks 'India Leadership' on linkedIn, I did come across a interesting question as follows: "Tens and thousands of millionaires and millions of hungry/poor people in India!! How can this contradiction exist?"

My thoughts: The "distribution" of "Intention" needs to be fixed. If 'rice' is an intention, then we need to fix the distribution problems which amounts to 45% of wastage as per stats. If 'positive thought' is an intention, we need to enable effective distribution of this to reach to enough people who can make this actionable (Lynch pins). If 'money' is an intention, then we need to hold the distribution of it accountable, that, they have done enough research to economize and invest in important problems (as against urgent problems as well). if 'leadership' is an intention, we need to hold the democracy as a collective system of distribution to elect and hold these leaders accountable. Why? because, hunger, pain and suffering are viral. Their efficiency to distribute and replicate by far outweigh the positive systems that are in place in the eco-system.

Can this hold true for the "product start-up" debate as well ? I think so. The distribution of Intention is the biggest problem we as a country are facing now to enable positive sustainable eco-systems. Here is a link on those thoughts.

Misery loves company.

What does it take to create successful IT product companies in India?

This thought keeps bothering me off late. Many have beaten this debate to death. I am still not at peace. What does it take to create more 'successful, innovative' indigenous IT product companies in India ?

Approximate guess says that we have less than 1% 'successful, innovative' IT product companies in India. Enough hypothesis, conjunctures and theories have proven that product based solutions (due to replication of effort and automation) provides significantly higher bang per dollar invested than services based solutions. Scaling of services is resource intensive and puts strain on economies of scale and scope. Why are we not there yet? What happened ?

Are we genetically at a disadvantage ? Are we less risk prone ? Is it a geo-political conspiracy ? Are we capital averse ? Is service mentality ingrained in our culture ? Argumentative Indians, by virtue of our intellectual pluralism have wisely concluded that Services-for-Life leads to Nirvana ?

I admit I am naive. Yes, it was beneficial to apply economies of scale and cost arbitrage creating large amount of wealth for the nation. Yes we are moving towards value arbitrage (premium services) and upping the ante. But, this just cannot be 99% of what we do in IT.

Through and through, we have been both perceptually and conceptually primed through our success in services, so much so, that we are unable to (even if we desire) embrace the paradigm shift towards products mindset.

Successful products model is R&D intensive, bets on disruptive innovation (serendipitous), is technology intensive, utilitarian and demonstrates high tolerance to creativity. Yes, "tolerance to creativity". Creativity puts focus on the individual as against focus on the group. Services model benefits from focus-on-the-group as it creates uniformity and conformance. There is a world of difference culturally in these models. You can see the culture shock and pain one goes through when a person moves from a product company to a services company and vice versa.

We need to reverse this priming. We have to focus on Indian product startups (Big companies are hard to change) and foster a eco-system which benefits product startups. We have to glorify the product model to 'exaggerated' proportions. We need to 'invent' heroes to win quick sub-conscious battles and influence the psyche. We need war veterans 'imported' to teach us the trade. We need 'real' angel investors and significant hand-holding for new startups. We need favorable business incubation centers through a Govt. endorsed PPP (Public-Private-Participation). We need to fix our priorities.

We may lack many things but cannot afford to lack priorities. If we are presented with a deaf and a blind, then, a deaf leading a blind is always better (than other way around). Vision needs to be higher in priority than the ability to hear (to the potential market). Market vision comes from innate ability to identify latent demands. How does one harness that ability ? How can we identify and nurture Visionaries ? Do We need a Revolution ?

---
Addendum: The definition of a services company in this post is any company providing solutions which are labour intensive similar to the big 3 IT success stories in India. Not to be confused with software as a service or social networking services or b2b/b2c services which are driven by platforms/products.
---

What will you do ?

"What would you do if your were the last person on earth?" - A simple question.

Most of the people whom I interacted with on this question, responded with the following set of emotions: Despair, Attachment, Experience, Learning from the past... Deep brow, Thoughtful, Effort to reinstate the past.

Now I asked a different question to different set of people

"What will you do if you were the first person on earth?" - Simple again

This time around, the answers portrayed Desire, Hope, Passion, Trying things... Open, Thoughtful, Willingness to create the new.

Try this your self. Ask a few.

Its perplexing and amazing how much of a difference a change in the worldview makes. In both cases you were alone in the world. The thought of end-of-the-world or beginning-of-the-new made such a vast difference in the way people perceived how they would behave.

What will you do if its your first-job or last ? your first assignment or last? Your first start-up, will this be your last ?

Right Casting your Core

If you are a startup and looking out to build a core team, think through on what type of people you need. Being part of several start-ups in the past and also currently being a founder of a new one, I understand the constant pressure you might go through to find the team. My personal opinion and observations on this (more of a philosophy) is not to hurry or compromise.

Do not fall into the valuation trap to bring in high-fliers and experts in their respective fields. On one side, even if the chemistry works and the people you are bringing in are experts, if they do not have enough important work to do, then, you land up diluting the interests and morale apart from the equity anyway. It is OK if you pass on great people. Make it 'equitable' for the organization and the people you bring in.

On the contrary, keep the focus on getting people with passion and who are willing to take up work beyond their capability. This has magical effects on the productivity of the team as well as the morale. I have first hand experience of this effect in the recent past. A sense of camaraderie is what makes a winning team. I have seen and heard of teams with real high fliers and the CEOs fulltime job in managing egos and fire fights.

Of course, promote the strengths and augment the weakness with advisors to the board and external help from the network. You would not want to set your core team up for failure if they absolutely lack capabilities and are just full of passion.

In short, Keep the focus on the core, promoting people with passion and assign accountability and responsibility greater than their current ability. Reduce the bling effect. You do not need big guys for valuation. This philosophy works at all levels apart from the core. Try it. Let me know.

What do you do ?

Old Grandpa decided to take little Yajur to a field trip on Yajur's 5th birthday. Grandpa choose a factory which makes awesome mousetraps for the field trip. On the day, they walked into the factory, Grandpa instructed Yajur to ask as many questions as he wishes.

The field guide decided to take them to the manufacturing department first. Yajur asked the chief engineer what they are doing ? The Chief engineer said they are building the most awesome mousetrap to catch a mouse. He explained that his team is responsible to make the trap so efficient that the trap closes in super-duper-speed as soon as the mouse enters the trap.

They went to the R&D department next, Yajur asked the same question. What do you guys do ? The Head of R&D explained, you see, we are inventing the yummiest cheese to attract the mouse to the trap so that we can catch the mouse. Our research says that it is not the mouse trap but the Cheese which matters the most.

Next, they went to the marketing department. What do you guys do ? The Marketing Chief said that his job is to put the mouse trap in the most colorful boxes so that people can like the package and buy the mouse trap to catch the mouse. He also said he conducts market research on 'positioning' the mouse trap in the right place so that people can improve their chances of catching the mouse.

Next they went into a big awesome room with a nice view. The field guide explained that this is the 'Thinking' room where the CEO, the advisors and experts discuss and innovate. Yajur walked up to a expert/advisor and asked him what does he do. The expert said, see little boy, we invent new ways to catch mice. Mousetrap is only one way to catch the mice. We provide solutions to come up with newer, better, cooler devices to catch the mice.

Grandpa and Yajur were driving back home. Yajur was all along looking confused, so grandpa asked Yajur whats' bothering him. Yajur questioned back hastily, "But, grandpa why do people catch mouse?", Grandpa said, to get rid of it as its' a pest in the house. More confused, Yajur quizzed again, but, do we need to catch the mouse to get rid of it? Grandpa smiled and knew that the day's wisdom has been delivered.

Quantama Hiring Call - In Retrospect

In retrospect, this call for action on Venture Woods brought in the highest calls and reactions for job application to Quantama on March 2009.

The Job posting excerpt:
------
I am looking for people with entrepreneurial bent of mind to join the founding team of Quantama.com a mobile proximity company. I have the business case validated and have one of the largest retailers in India showing Intent to implement when the product is ready… Angel rounds are being vetted and talks in process… Have product case and prototypes in development…

The markets we are addressing are emergent and pervasive… A distant fortune is heard of…

I promise you that your experience shall be cast with risks, hardship, pain, sweat and blood. The journey will be turbulent given the economic times.

If you see providence where others see peril, do get in touch with me for more detail and I shall be glad to consider a sitting…
------

Serendipity is the Key.

Most of the established businesses get into a pattern of finding out what is working and doing 'more of it'. This is good for bottom line, margins, and retention of your existing customers. But, is it good for breaking new grounds ? Making the pie bigger ? Your Top-line?

Business-as-Usual is to work hard consistently, trying to cash out on the idea that made the business successful. They work hard at establishing Cliches. Cliches are good. They are 'time immemorial'. They express ideas in simple words, but they lack the freshness and eloquence of a magical orator. If you have read the blogs of Seth Godin or heard president Obama speak or have followed the marketing of Apple, they do not rely on Cliches. They break the mold, create new meaning, speak different truth, change the worldview, present their stories in a more innate yet excitingly new package. They are Contrarians. They are Serendipitous. Here is what Seth Godin has to say about Cliches

Imagine that you are a T-Shirt vendor with a inventory of T-Shirts made of several attributes. Lets say you have 4 sizes (S, M, L, XL) and 4 Colors (Red, Blue, Green, White). When you first set shop, you do not know how many of each T-Shirt variant to carry (how many of Blue-XL will sell?). So you start with 10 shirts per variant combination and open business. Now, the first month you sold all the Green-L shirts, some Blue-XL and none of the others. What do we do? We decided that Green-L sells more in this catchment and order a bigger inventory of Green-L and lesser of others (Finding out what is working and doing more of it). If for the next few months, the trend continues, then, going by the pace, you may land up being a Green-L T-Shirt vendor. Its obvious that the more Green-Ls you have, the more your sales-report shows that you have sold the same. You already know whats wrong in this analogy. Yes, its a simple example, its so easy to see. Its a no-brainer.

But then, how come you do not see this analogy in the business strategies you follow ? How come you are not trying to find out what else your consumers are willing to try ? Why do we intellectualize for ages on why something "may not" work because "your" past data provides facts to your beliefs. Is it Fear ?

Start-ups on the other hand does not fear to be serendipitous (In a way, they have nothing to loose). An entrepreneur identifies an opportunity to make meaning. A passion-fruit colored T-Shirt, A Vanilla-Sky colored Tshirt. Try something afresh yet innate. Change the fabric, the texture, the weaving, the grain count, whatever... But be eager to explore, break the Cliche, turn it upside down. This is why it works and new tribes are formed. This why the most successful ones are Genre-Bending.

Every time you support your views on past-data, think again. Question yourself. Give Serendipity a chance. Believe in the art of possible.

Shared Consumer Data, Reciprocal Marketing and Conversions for Retail

Reciprocal Marketing is not a new concept in Retail marketing in India. Mostly in the B2B segment where promotions, cross-subsidy and cross-sale combinations exists. Insurance is offered for people who open bank accounts. Credit cards are offered in conjunction with book buying (landmark). Money back when you fill gas in a IBP station on debit cards etc... All this hints towards sharing the consumer (data).

To carry this to the next level, it is important for Retailers to come out of their shell and stop worrying about 'who owns the consumer data'. I keep getting into all sorts of debates and uncertainties of why Organized Retailers should or should not expose their Consumer data. The claim for not exposing is that, clean data is expensive and the IP differentiator for better conversions and loyalty for a given retailer, so the data should be owned and not shared.

But what is clean data ? How do you validate it ? How do you maintain it ? What is the cost of logistics ? What is the strategy for conversion ?

Clearly, the sum of cost of solving above hurdles for "clean consumer data" is significantly higher for the Retailer before gaining any benefits from such a data if each and every individual Retailer repeatedly manage their own datasets. This is why there is a half hearted effort by every Retailer. Nobody seems to have walked the whole mile (maybe except the Gas Agencies as its a regulatory body and they must validate). Consumer Loyalty forms, credit card records and Home delivery challans are the only validators existing today. Among this, credit card companies will not authenticate the consumer info fully. Payment gateways are a black box. Obtaining consumer psychographic details is a costly research and catchment exercise.

Instead, why not free the data ? Put it up on a "Consumer Data Cloud". Open the collaboration of consumer data by offering direct incentive to the consumers for maintaining and upkeep of their own info (with a shroud of privacy). Technology exists for this today.

Sharing the consumer data across segments shall be the next disruptive wave to change the Retail horizon.

The time has come to reap the benefits of open collaboration (Given that consumers are readily pouring their life's worth on Facebook, Twitter, MySpace and the rest of the Ning bases). Yes, privacy is a concern. Privacy must be the focus while collaborating such data independent of whether it is on a Retailer's platform or otherwise. I would go a step further and argue that privacy can be better managed, audited and assured if consumer data is managed as a single source of truth (single cloud). The cost of assuring privacy for such data for every Retailer on their own infrastructure is high and incredulous !

The benefits of freeing consumer data ?
- Pruning of costs across CRM which releases fairly significant chunk of capital. A portion of that capital can be re-purposed for interacting with the 'consumer data cloud' (smaller than the cost of managing your own dataset)

- Single source of truth both for the Consumer and the Retailer. Consumers especially can have a single pane of glass across all their Retail outlay (visits, purchase, spend, loyalty points). Retailers of course benefits from higher analytics and trending across consumption lifecycle of the consumers.

- Enablement of a Co-Opetition framework where Retailers can co-operate as well as compete for the Consumer's attention. This is where true reciprocal marketing evolves. Cross loyalty, cross segment combo kits (dinner and a movie package), targeted promos, cross segment redemption schemes will be more meaningful and rich in ideas and innovation.

End result? better engagement, targeted touches, hand holding across consumption lifecycle, point discounts, higher redemption and yes, absolute conversions. Sounds like utopia, maybe not. But truly a step closer.

All this and more is possible only if Retailers break their shell and hatch. Its about time the data is free (as in freedom)...

The Worth of Value

How does one sell in a down economy ? Given that consumers are becoming value conscious, many of the Retailers I am speaking to are seemingly trying to answer the question "How do I assess, reach out and offer what is 'valuable' to consumers contextually ?

Why is Value contextual ? Because, it is based on the end user, end-usage and the environment. This is a coarse grained dimension of Value. Let's delve into the intricacies further and understand this point.

Marketing gurus exemplify that other fine grained dimensions of value exists.
- Value is Relative; relative to alternatives available within the given context.
- Value is Perceptual; driven by the current senses.
- Value is Provisional; New information can change percepts.

Given these, the dimensionality of value from a economic perspective brings in the concept of the "worth" of value. The risk in acquiring a value target determines the worth of the target.

So are consumers really value-conscious or worth-conscious. I guess they are both. Once they (some how) determine that something is valuable, then they start seeking to find if its worthy. How can Retailers determine the worth of a value for the consumers? For one, the worth is driven by what the consumer perceives as intrinsic risk in acquisition of value. Mostly, the risk of "being wrong" in whatever sense it may be is the biggest risk I foresee in determining the worth.

What if I paid too much ? What if I could have got a better product at the same price ? Does this look good on me ? What does my spouse think of it ? Does this product convey a better meaning of me (Cool, Smart, Sharp) ? Is it hygienic ? Do I have place to keep it ? etc... etc... are the risk driven questions in the consumers mind.

The exploding choice of products providing same/similar value is going to add to the "risk quotient" in determining the worth of value. The lesser the choice, the higher the worth. The higher the worth, the higher the price.

In essence, it does boil down to offering value to consumers across all dimensions while making it worthy (Branding). Especially from the dimension of 'Value being provisional' where the Retailers provide differentiated clarity for the value being offered. Providing that differentiated clarity should start way early in the consumption life-cycle. Typically the consumption life-cycle from a consumer perspective (Not the retailers perspective) is across the phases of Awareness, Research, Transaction, Delivery and Consumption. It is primarily important that the clarity is provisioned through out this lifecycle.

Providing clarity requires personalized touches and individual reciprocation with each of your consumer. Knowing the consumer including likes, dislikes, opinions, past purchases, current context, psychography etc. along with the intrinsic knowledge of the product assortments offered is a requirement. Building a value/worth grid based on this knowledge is essential. Engaging the consumer interactively through differentiated (not different) marketing channels is important. I guess this is the place where technology should gear-up to enable the "Experiential Economy" to make the while worth.

Convergence of Proximity based Technologies, Social Media, Collaborative Filtering, CRM and other such Simulacrum may offer probable solution. It shall be some while before true convergence can happen. Disruptions in marketing channels, technology, loyalty programs, product management and category management may be inevitable before it gets worthy more than valuable.

The Experience Economy of Mobility and Convergence

The Experience Economy specifically in the convergence and mobility (as in mobile based) sector shall gain new heights both from a continuous and dis-continuous innovation.

Why ? Purely because of the disruptive nature of just having more bandwidth on majority of the handsets across social strata.

Experience economy as defined is the orchestrated events made memorable to the consumers which collectively by in itself becomes a "product". Flashback to the Movie "Minority Report" in which Tom Cruise walks through a shopping mall and based on his iris scan, he gets beamed with relevant promotions within the vicinity that is specific to his profile and custom tuned to his liking.

Though I will not get into the super cool ingredients that may go into making this sci-fi happen today (as I am ignorant), I am fairly confident that a similar (diluted) experience can be achieved using the Mobile devices. Ability to ID the consumer through the device, Cloud Compute servers to crunch and store relevant Consumer Info (considering privacy), Relevance algorithms (similar to what is being used in NetFlix and Amazon) exists in one form or other. The missing ingredient was ubiquity of bandwidth on mobile devices.

Bandwidth hurdle being removed (3G, Bluetooth 2.0), the play will boil down to "What is the best impact provided during the time of maximum exposure ?". The time of maximum exposure is when the consumers is in your store or the shopping mall, browsing.

As arcane and cryptic as it sounds, there in lies the key for many new entrants and start-ups opening up new market categories. Each player can significantly differentiate themselves by choosing the right attributes to own.

Quantama is one of such start-ups creating a new category in the mobile proximity space for Organized Retail. Stay Tuned...

Emerging Business Drivers and Orthogonal Validations

Rapid Adoption of IT systems across sectors and Domain: Globally as more and more systems are being digitized, the need for testers have increased drastically. The availability of the resource pool who has the necessary domain knowledge is also shrinking which has lead to a resource pool crunch. That said, it would be paramount to ramp-up Business Analysts and Product Primes to acquire the pre-existing knowledge within the domain and innovate upon that knowledge. Bringing testers up to speed then becomes the responsibilities of the Analysts and Product primes. The secondary problem of non-availability of Skilled (automation scripts) testers to perform the necessary functions gives raise to a requirement of machine based frameworks to fill in the gaps of non-availability of the resource pool. This gives rise to the lateral industry of automated code generation for developers speeding solution development as well as automated test case generation aiding the Quality Assurance folks. Business Analysts are demanding tools which enables them to create test scenarios without having to write code.

Impedance mis-match during knowledge transfer: When the knowledge transfer of the Domain has to flow from the Analyst to the developers and testers, the impedance mis-match in translating the knowledge in terms of articulating the nuances of the innovation and the capability of a tester (as per say) to understand and assimilate that knowledge into the respective Testcases is mind numbingly high. This high mismatch in what was expected to be built and tested and what landed up getting built and tested will lead to heartburns during acceptance scenarios. Demand for extreme traceability of Testcases and test steps to the requirements has increased rapidly.

Complexity of the Product: The choice of the technologies and frameworks and platforms used in manufacturing and building the solution also adds up to the complexity of the test cycles. ERP implementation, PDLC of a Enterprise Product, SaaS based Solution Delivery, Cloud Compute enabled solutions, Data Center Management, Legacy Integration etc, are not only rich in semantics from a Domain perspective but are also complex to assimilate to understand the breadth and depth of testing strategies required to validate and provide assurance of quality. Demand for pre-built adapters and catalogs which can readily integrate and work as expected during last mile integration is on the rise.

Heterogeneity of the Systems: Added to the complexity of the product, the IT eco-system in which these product operates today are made up of different systems from vendors such as IBM, Oracle, Microsoft, SAP, Sun, HP etc... (including home grown solution) that contains various platforms patched up together through ESB and SOA integration. Even the choice of Operating systems and hardware platforms have become varied that performing a configuration and version compatibility test for any given platform has started to look daunting. Virtualization and Automation is becoming the norm of the day.

Shrinking GTM and Focus on short gain cycles: Typically the Product development lifecycles and Go to market cycles are shrinking in the light of ever changing business dynamics. Every one wants to put the product out in the market as soon as possible capturing the customer share as soon to gain control on the changing business dynamics. Agility, it seems is paying dividends for such short GTMs and providing a quick ROI. SaaS based and On-line solutions are moving towards perpetual beta platforms which can rapidly adopt to the customers needs. This also holds true for ERP implementation cycles which are shrinking by the day. What used to take 5 years are now being reduced to 1 year implementation cycles with rapid customizations. Demand for baseline Testcases covering top few probable customizations of a large product base is increasing. Pre-built Test Content 'cartridges' are the need of the day.

Shrinking IT Budgets: Discretionary spend has been monitored more closely and also the overall IT budget is shrinking by the day. CFOs are breathing down the CTOs neck for efficiency and productivity for every dollar spent. This has lead to cost cutting in terms of support staff (people) and reduction in spend of applications and products (license). CFOs are moving away from making any large capital commitments at the outset impacting high CAPEX vendors. Converting the fixed costs to variable cost is the Financial Officers edict across LOBs. Demand for subscription based usage is on the rise.

Global Recession Driving Margin Pressures: Global recession being the new reality, the pressure on margins (not to mention survival) is high. Corporates are looking for operational efficiencies to increase the margins to retain the operating profits while the top line sinks. Increasingly corporates are betting on digitizing and automating all processes that can be automated which shall convert to cost savings by downsizing the cost centers. Demand for outsourcing the validation and assurance and SLA management is on the rise.

Demand for Highly Reliable Products and Service: The general tolerance for a good quality product has come down. Consumers are demanding 'excellent' quality products. In effect, what was excellent yesterday is just good enough today. Reliability and Relevance are the two parameters that are driving the world markets. If a product or a solution is not meeting the standards of 'excellence' then there is no place in the market for the solution. Corporates are trying to leverage machines (computers, robots, software) as much as possible to automate the core solutions. Automation unlike manual processes provides a high degree of reliability when employed through out the production cycle. Demand for metrics based reports with high degree of SLA while enabling automation is on the rise.

Regulatory Compliance: With the increase in the number of regulations in any given sector (HIPAA, SOX, GLBA etc...) the burden of certifying the product, platform, application or service has increased dramatically. This has led to the amortization of working capital from core production cycles (bread and butter cycles) to compliance activities. Given the same capital budget (which seemingly is shrinking as we speak), the number of activities in production has increased to cater to the compliance demands. Corporates again are seeking automated compliance testing tools to ensure certification which increases the operational efficiencies. The compliance requirements has made the corporates to refactor the dynamics of a verification and validation LOB from a cost center to a value center. Demand for compliance catalogs for verification is on the rise.

Increased Threats and Security Compliance: The threat levels have been ever increasing and the types and nature of threats have become innovative. Security Compliance has become a core activity of any validation cycles for products and solutions. Penetration testing, Functional Security, Security Standards Compliance etc... adds to the release and build test cycles as a natural PDLC flow increasing the number of core activities to be performed by QA. Corporates and QA departments are seeking automation platforms in these and other areas to release enough bandwidth of the existing people so that what has to be (and can be) performed as manual verification has enough people available to perform. Growing need for security verifications as part of the automation solutions is been on the rise.

What does these emerging drivers means for Verification and Validation process ?
Simply put, testing is not a gating function anymore. Testing has become an inherent QoS (Quality of Service) through out the life cycle of production or service delivery. Testing has become a change agent addressing risk early on in the lifecycle and continually assuring reliability, relevance, Security and compliance apart from providing functional acceptance and assurance for the product or service. Testing as per say has become a value creator and quality differentiator for the end product to provide the required edge to compete in the market place of excellence. Testing has become an "Orthogonal" platform, process and activity to cater to the demands of the new markets.

AutoCzar a test automation platform seems to be reinventing itself to cater to these emerging trends.

Mobile Call without getting Billed

Convergence along with Innovation is a deadly concoction. It has been said that no power in the world can stop an idea whose time has come. So it seems for Cherry a Belgian Tech Startup in the Mobile MVNO space. The coolest thing about this innovation is the ability to make calls to the people in your contact list without using a SIM card. No I am not smoking, YES, ITS WITHOUT A SIM CARD.

The technology uses a "handover" protocol as reported whenever in the vicinity of a Wifi range. There is a application required to be installed on the phone that shall seamlessly switch between Wifi and GSM. Interesting and Exciting. Read more on this here...

New Venture (Quantama)

My last blog was quite a while back. I was caught up (lousy excuse) in establishing a tech-start up. I am currently working on a mobile proximity start-up focusing on Consumer Lifecycle Management for organized Retail (www.quantama.com).

Finding seed capital during recession, working on positioning for new market, getting a core team in place and getting the first customer on board have its own share of anomalies. Added to that, learning of things that you may have seen or done before all over again for the new market realities is an exciting challenge an entrepreneur may grow up to appreciate. In fact there is a sense of vuja-de experience (things look new even though you may have done them before) this time around.

Deep down inside, I know that all the positioning I perceive for the product before hitting the market is a preparation in principle to be able to cope with the game changing realities once the product rolls to production. Eventually the market shall position the product. The trick is to plan enough to minimize the delta efforts to reposition. This time around, I 'seem' to have understood the philosophy of "Flow with the Go" as Guy Kawasaki puts it in 'The Art of Start'... But the best is yet to come...

As Frank Sinatra's Song goes:
"Out of the tree of life, I just picked me a plum
You came along and everything started to hum
Still its a real good bet, the best is yet to come

The best is yet to come, and wont that be fine
You think you've seen the sun, but you aint' seen it shine"

I am hoping that this time around that I see the sun shine...

SaaS'y Benefits

SaaS or Software-as-a-Service as it is coined is the ability of a external service provider to provision a business service over the internet so that it can be consumed remotely by (mostly) enterprise organizations. The luring drivers for running software as a service stems from its propositions of the ability of a external service provider to apply economy-of-scales for either IT operations or applications to offer better 'benefits' to the consuming organization. benefits such as cheaper costs, high availability and better scalability are promised and seemingly delivered.

Non-SaaSy Enterprise (Business as Usual):
In fact, since IT spend happens to be one of the key drivers which is driving the SaaS adoption, lets take a look at the average IT spend and the proportions of such spend broken down into line-items spread between the CAPEX (Capital Expenditure) and OPEX (Operating Expenditure) of the spend.

Here is a table on the cost breakups as per Gartner's survey on annual IT Staffing and spending:


70% of the IT spend comes from the OPEX per annum while only 22% comes from the CAPEX. Focusing on the OPEX, we can see that 32% of the OPEX is due to Internal Staff (which is also 22.4% of the whole IT spend) and around 21+17+14=52% of the OPEX coming from Hardware, Software and Telecom. here is a pie chart to display the breakdown.


Now this being the BAU (Business As Usual) cost break downs, how would making your business SaaS'y benefit your bottom line?

Benefits offered by SaaS Model
SaaS as defined is a outsourced model which allows services to be accessed through the internet remotely by the consuming organization. Saying this from a 'SaaS providers' perspective what are the benefits a provider can offer and how can the provider achieve the same? Some of the benefits proposed by the SaaS model are as follows:

• Service at Cheaper Cost
• Better SLA than internal IT (Scalability, Availability, Performance, Maintenance, Upgrades)
• Accountability

I would strongly advice the readers to read the Microsoft article titled "Architecture Strategies for Catching the Long Tail" to understand the intricacies on how these benefits are provided.

- Cheaper Cost: the SaaS providers can offer cheaper cost by employing what you call as a 'economy-of-scale'. A SaaS provider (based on the maturity scale he is in) does offer the same service to more than on customer. This allows the SaaS provider to share common utilities across multiple customers. This allows the provider to spread his cost across customers bringing down the overall cost of operation for the provider. The provider eventually passes on such cost reductions to the customer by charging lower for the Service.

- Better SLA: Similarly, the SaaS provider can employ clustering, grid computing or elastic compute cloud that is offered by some of the 'utility computing' enablers to leverage a managed and virtualized infrastructure to bring down the providers overall TCO (Total Cost of Ownership) of running his operations across customers. The economy of scales in virtualization of systems and elastic compute clouds (Amazon EC2) does offer exponential benefits as computing volume increases. This not only results in further reduction in cost of operations but also aids in better SLA offering. SLA's such as Availability, Scalability and Performance are inherent to such utility architectures.

- Accountability: Since SaaS providers play as external vendors, the legal obligations and contracts will implicitly be more stringent than the contracts with the internal IT. Also, Since SaaS providers are 'in business' selling the proposition to be profitable will have genuine interests to make the model equitable (I am not accusing the internal IT here). Saying this, the accountability also comes from the fact that the operational model of SaaS enables the consumer to get a metered/leased billing frequently (at the end of billing period) that allows a detailed break down on the usage of services. The service usage if subscription based is simpler to manage as against a 'transaction pricing' model. The transaction based pricing also refereed to as pay-per-use or pay-by-the-drink requires operational infrastructure available at the SaaS providers end which can enable such metering (more on this on further blogs). Such metered usage allows both 'throttling' of usage both by the consumer as well as the provider. A SRM (Service Relationship Management) office at the providers end will ensure constant support (with support SLAs) probably better than the internal IT (due to economy-of-scale again). All this ensures that "IT as a Business" is more realistic to run by being SaaS'y rather than trying to make the internal IT run there process as business.

Given these benefits, it makes sense to reduce the internal IT spend across the CAPEX and OPEX as shown and start considering IT as a 'service center' instead of a 'cost center'. The benefits of a reduced TCO as well of a higher ROI (being a service center) are seemingly guaranteed (again based on what maturity level of SaaS is being embraced and the overall IT policy). Rationalization of the IT Governance structure as well as obtaining executive sponsorships can be real hurdles for initiating the programs (as these benefits are not been qualitatively demonstrated by many vendors yet).

This said, Enterprise still needs to go through a paradigm shift in their operations to embrace SaaS into their ITEcosystem. Questions such as :

• Enterprise efficiency and operational changes for SaaS Vendor Management.
• Enterprise Integration of SaaS systems into strategic systems that are running internally.
• Integration and collaboration of SaaS systems across SaaS vendors.
• Enabling business process orchestration that is seamless across the IT Ecosystem.
  
• Regulatory Compliance rules for SaaS engagements.
  
• Enabling and Tracking of a 'Process Health Matrix' to monitor the overall benefits across enterprise IT ecosystem to see if transforming few LOB applications in to SaaS is not jeopardizing short/medium term goals of the enterprise.

etc... are some of the challenges that still needs to be addressed before getting on to the SaaS bandwagon.

The Long Tail of IT Spend

'The Long Tail' is a 'power law of distribution' used by statisticians to define a expanding market (in any given discipline that is) in terms of the economic and business model of the market. In fact the phrase 'The Long Tail' was coined by Chris Anderson (editor-in-chief) of wired magazine. In simple terms the long tail can be explained with a graph as follows:


This graph compares the total average IT spending of organizations of differing organizational sizes. Notice that the graph has a 'Big Head' with high amplitude but is immediately followed by 'The Long Tail' of lower amplitude (or spending) organizations. Though this graph is not 'explicit' in denoting that given the universe of discourse of all organizations which spends on IT, The top IT spending organizations ('The Big Head' of the curve) will still fall short of the collective 'volume' of IT spend that occurs on The Long Tail. This is seemingly true because the 'number' of organizations with a high IT spend are relatively (significantly) smaller than the overall 'number' of organizations who are spending on IT. In short, the spend volume of small number of high-spend companies is lower than the spend volume of large numbers of low-spend companies (huh).

This theory holds true in other areas as well. Ex. The Amazon business models. Amazon as a service provider over the internet can cater to this long tail of business easily compared to the brick-and-mortar bookstores such as barnes and nobel or borders. The 'easiness' comes by the virtue of offering the 'book store service' over the internet. As amazon does not have to maintain in-store inventory, it can almost have a large warehouse of 'all' kinds of books and deliver it directly (probably from the factory warehouse in some cases) to the consumer. The 'Top Sellers' which are relatively few in number makes the big head, compared to the rest of the non-top-sellers which makes up the Long Tail. In 2005, 50+ percent of Amazon revenues came from the Long Tail. The last I checked (in 2007) this number was at 25+% (percentages are deceiving in the way you read them).

Here is another graph that explains the long tail of music industry that depicts the average number of plays per month for music available in Walmart and Rhapsody.

Coming back to the point of the Long Tail on IT spend, there seems to be a burning question (mostly as i see it) that needs to be answered about

"identifying business models that can be considered to solve the reduction in costs of IT operations in any enterprise (whether its part of the Big Head or the Long Tail)."

Before answering that question, its worth taking a brief look at the SMB (Small and Medium business thats part of the long tail) market which makes up the IT Spend accounting to 150B$ (Yes thats estimated at 150 Billion Dollars as per IDC).


Its also worth reading the article titled 'The IT Market’s $150B SMB Long Tail', published by Frank Gens who is a senior VP of research at IDC.

Seemingly, both in the above article and also mostly elsewhere the answer to the question seems to lie in SaaS (Software as a Service). But can SaaS really answer the question to cater to the SMB long tail?... It remains to be hypothesized...

Architecture Process Framework

For several years and across several product development engagements, I have come across varied organizational structures and 'disparate' architecture and development processes that I thought I must reflect upon my own understanding of these ideologies and present a 'process simulacrum' that I have been able to assimilate over time. In essence, the simulacrum is based on varied development methodologies such as RUP (Rational Unified Process), Agile UP, XP (eXtreme Programming), SCRUM, DSDM (Dynamic Systems Development Method) etc...

This 'process simulacrum' is not general purpose. In my mind, the process I will present in this article will be applicable to technical architecture process as against a overall functional PDLC.

(Caution: I have 'tried' to keep the article short, but have justified the definitions of some concepts, which makes it a rather longer version of a blog.)

This technical architecture process will emphasize the process workflows necessary to enable the “core platform” of a given product. The process will also help establish a “technology change management” practice within the product lifecycle. It will also accommodate any technical/technology POCs (Proof of Concept), early architectural spikes and prototypes required for the functional architecture of the product.

The overarching vision of this process simulacrum is to aid in objective evaluation of the architecture/technology in context so as to provide unbiased feedback to the organization to consider appropriate decisions during the overall product development roadmap.

Let us start with a workflow diagram that denotes the flow of process as well as artifacts (mixed into one). I have kept the flow as simple as possible so that its easy to augment the process into both predict frameworks such as RUP as well a agile frameworks such as Xtreme Programming.


Going further the blocks within the workflows for the given process is explained in detail.

1. Technology Management

The charter for technology management includes:

• Deriving a technology roadmap
• Establishing the roadmap within the organization
• Seeing through the execution of the roadmap and
• To optimize the roadmap based on changing product and technology requirements.

A technology roadmap is different from an architecture roadmap. In it, a technology roadmap manages the external and internal (home grown) technologies that can be used to manufacture the product or aids in animating the product manufacturing process in itself. Typically a technology change management governor (or council in case of very large organizations) owns the responsibility of technology change management to drive the road map.

As an example, a technology roadmap is made up of:

• Technology compliance entities such as compliance for J2EE or .NET. (versions included)
• Third party integrations based on buy vs builds
• Migration paths such as Oracle 8i to Oracle 10g, J2SE 1.3 to J2SE 1.5 etc… (includes EOL derivations)
• Framework implementation milestones such as Struts, Spring, Hivemind, etc
• Tools implementation for roundtrip engineering, engineering performance, code coverage etc.

Technology roadmap is a subset of the overall architecture roadmap. In addition, the Architecture roadmap owns the conceptual entities specific to the overall functionality of the product:

• Specification compliance entities such as JSR168, JSR170.
• Meta standards compliance such as CIM, DCML etc.
• Concept/Process compliance such as SOA, MDA etc…
• Domain specific implementations such as CMDB/SMDB, Multi tenancy.
• Core enabling module milestones (relevant to platform) such as security kernels, web services, edge integration frameworks etc.
• Compliance architecture for regulatory standards such as SOX.

Core Activities of Technology Management includes:

1.1) Technology Requirements Analysis (TRA)
1.2) Technology Lifecycle Management (TLM)
1.3) Deriving Technology Roadmap
1.4) Buy vs Build Analysis

1.1) Technology requirements analysis (TRA) : this activity derives the technology requirements necessary for the product. Also, a technology usecase (where relevant) must be derived within this activity. A technology usecase is different from a functional usecase. In a technology usecase the product use of technology is depicted (Example framework, libraries, toolkits) as against a functional usecase. Deriving the technology requirement for the product is part art and part science. This is because the requirements are heavily bounded by three influencing factors namely

• Business need and value add: The business need is the heaviest driver for the technology requirement. The requirement must always materialize into dollars earned or saved. Economic feasibility analysis is the key for validating the technology requirement against the business need. (Sub-Activity: Economic Feasibility Analysis)
• Market maturity of the technology: The next priority would be to understand the industry maturity and acceptance of the technology. A bleeding edge solution in most cases is always pre-mature to implement. And not all legacies are always meant for a sunset. Understanding the market progress and industry acceptance for timing the technology is always a balancing act. (Sub-Activity: Market Maturity Analysis)
• Product readiness for the technology: Lastly the product readiness to implement the technology within the product needs to be established as a part of the process for validating the technology requirement. (Sub-Activity: Product Readiness Analysis)

1.2) Technology Lifecycle Management (TLM) : Technology life-cycle management includes the management of the existing technology components within the core platform of the product. This includes maintenance and optimizations as well as migrations and upgrades. This activity also manages a config map (or an inventory) of the current technologies used within the product and the respective status of the technologies. Example of technology status could be “marked for migration”, “eol identified”, “current”, “legacy” etc… [I have a separate block and a section dedicated to this activity. Depicted in the diagram as 'Manage Technology Lifecycle']

1.3) Deriving the Technology Roadmap : As stated this is one of the core activities of technology management. Here a representation of the technology implementations, upgrades, migrations, and EOL (end of life) of the technology within the organization will be depicted based on a milestone within the roadmap. Mostly the roadmap will be driven through the technology requirement validated through the requirements analysis process. One of the other key input criteria for the technology roadmap is the product roadmap. The product roadmap acts a driver for the technology roadmap to validate the milestones for technology change.

1.4) Buy vs Build : One another important activity of technology management is to perform a buy vs build analysis for the product. This analysis can kick start a POC effort which emerges out of technology management discipline. The POC effort is depicted as a process stream within the technical architecture process workflows.

2. Technology Prototype

The technology prototype is a discipline or a process that enables activities for accomplishing architectural spikes or Proof of Concepts necessary to evaluate technology contenders (or architectural component) based on objective validations. The prototyping will be context specific and will be based on the nature of the POC required. The following are some case examples of the nature of prototypes:

• POC for a third party framework such as Spring or Hibernate.
• POC for a design threaded off from a functional implementation
• POC for a architectural component for platform services such as audit library, event managers
• POC for a tool such as code generators, transformers etc.

The purpose of a technology prototype discipline is to take the technology and product requirement closer to reality through objective evaluation of the concept through prototypical implementations. Also, the technology prototype discipline provides a controlled environment to fail within the given context bounds so as to evaluate the risks of implementation of a specific functional component or a technology component that gets embedded into the product. A prototype enables better control for risk avoidance/mitigation and reduces grave design flaws that may creep into the architecture.

Core activities of Technology Prototype includes:

2.1) Concept Analysis
2.2) Architecture Analysis
2.3) POC Construction
2.4) POC Documentation

2.1) Concept Analysis : First level theoretical evaluation for the POC implementation spawning the appropriate context for POC implementation. This phase is more to rationalize the scope for POC so as to not get carried away or overwhelmed with requirements not germane to establish necessary objectives. This activity will also help rationalize if the POC is necessary in the first place.

2.2) Architecture Analysis : once a context and a rationale are established through concept analysis, it becomes necessary to analyze multiple styles of architectural designs. This activity is more iterative and incremental in nature. Architectural analysis at the prototype stage tends to be driven by an “Agile process” to accommodate quick success criteria to choose a specific design (or a couple of designs) to implement in the POC construction phase.

2.3) POC Construction : POC construction is also iterative and incremental in nature, more so driven by an agile process to evaluate the best design for a given requirement. The POC construction will implement multiple architectural designs and will concentrate on quickly throwing away bad designs in the process.

2.4) POC Documentation : POC documentation is the most important activity throughout the prototype discipline. All the decisions starting from concept analysis through construction must be well documented to understand the merits of the decisions. It is very much necessary to justify the decisions through documenting the pros/cons, merits/demerits, implications, risks/mitigation and trade-offs made while arriving at a decision. Any compromise on the documentation will either prove costly at the later stages due to lack of understanding of a decision, or will expend unnecessary effort to recursively re-justify the decisions through unproductive means.

3. Feasibility Assessment

The feasibility assessment stage is to assess the feasibility and viability of the POC. This assessment is different from the feasibilities done at the technology management process block level. POC feasibility is done within the context of the architecture feasibility or the design model feasibility used within the POC from a purely technical angle. This stage is iterative in nature. When a given model is considered not viable for implementation, quickly the model is thrown away and a better design is synthesized for consideration. Feasibility assessment is also incremental in nature.

For example, during POC feasibility analysis, the POC conclusions are carefully evaluated to understand the trade-offs and merits with respect to the:

• Does complexity affect the deadlines (Design Patterns, Architectural Style, Algorithmic)
• Risks involved and mitigation strategies.
• Product architecture readiness to augment the design under evaluation (architectural integrity).
• Is there any platform design changes required?
• Is there any functional design changes required?
• Cost of implementations including effort per resource type and cost of technology (tools etc.)
  

Core activities of Feasibility Assessment includes:

3.1) Assess the Complexity of POC.
3.2) Assess the effort of implementation.
3.3) Assess the impact of existing milestone.

3.1) Complexity of POC : Complexity analysis is already mostly done during the architectural analysis activities within the technology prototype process block. During feasibility analysis, an overall analysis in terms of the augmentation of the design into the product architecture is conducted to understand the nature of changes involved for the existing product. These changes can be to the platform or to the application depending on the context of implementation.

• Gap analysis: Gap analysis will help understand the delta of all the changes required to implement the POC.
• Impact Analysis: Impact analysis will help understand the risks and efforts involved for the delta identified during gap analysis.

3.2) Implementation Effort : POC usually tends to be a quick prototype to establish an objective success criterion for a given technology contender to be implemented within the product. During feasibility assessment, it becomes necessary to project the efforts to get the real work done during the course of implementation into the product. Effort estimation is important to assess the cost of implementation. Effort estimates are directly proportional to the complexity of implementation.

3.3) Impact on existing milestone : project Impact analysis is based on the complexity of implementation as well as the effort involved during implementing the same. In effect, during project impact analysis, the effort is evaluated against the exiting milestones (even more important to the functional implementations).

4. Executive Committee Sign-off

Executive Committee sign-off is a discipline enforced for high cost, high impact project implementations. This discipline is exceptional in nature and will be exercised based on a threshold set for the costs, efforts, complexity, or delta etc.

This discipline ensures that appropriate visibility for high impact projects (POC implementation) are executed so that the executive decision makers can sign off on any deviations from the current plans, release, or technology.

Mostly, the sign-offs are required for project deviations, project cost/effort, or any other thresholds set as per executive will.

5. Technology Implementation

The technology implementation discipline helps in realizing the signed-off POC within the product. Technology implementation disciplined is reached only if the given context of implementation is any of the following:

• Platform component implementation (change)
• Framework, library, toolkit
• Third party induction into product
• Technology Migrations (Based on technology roadmap)
• Tools development for internal use (productivity, deployability, configurations etc…)

Technology implementation will be governed by the same principles that are applicable to all other implementation (construction) projects as well. The principles of iterative and incremental development, quality assurance and iterative release cycles are fully applicable here

Technology implementations will be governed by active architectural reviews of implementation to ensure proper design-to-code realizations of the proposed designs through POC. Architectural reviews and architecture assurance will be covered in detail later in the document. The following process flow helps emphasize the iterative nature of any implementation lifecycle.

Note: the implementations are influenced by “change requests” raised during periodic architecture reviews as well as “bugs/issue” found during quality assurance cycles

The implementations are subjected to unit tests, feature tests (based on technology requirements), and tests specific to architecture quality that includes modularity, configurability, performance, scalability etc.

6. Technology Quality Assurance

Technology quality assurance is a discipline to establish quality for all the technology components released to the base platform. Technology quality assurance activities, in spirit, are no different from the functional quality assurance activities. The only key differentiator here is the nature of requirements and test cases that influences the quality assurance process.

Technology requirements specifications document and use cases will be used to feed the test cases specific to technology QA. The requirements will be generally for the features or functionality of a technology component such as framework, toolkit or library.

Activities: All/any activity adjudged and obvious to the QA process (as decided through PDLC) will be applicable within this process. QA activity will be iterative and regressive to maintain multiple bug cycles during the course of the project.

Artifacts: The input and output artifacts will also be specific to the QA process as decided by the PDLC. Bugs and issues will be logged using an appropriate tool.

Key Note: More specifically, unit tests and code coverage must have very high emphasis during QA of technology components released to the base platform. Also stringent performance, scalability and modularity requirements must be specified as the core requirements for all components that get released to the base platform. Generally the code coverage percentage, performance numbers and load capacity must be relatively higher for base platform components compared to application components.

7. Core Platform Release

Platform release process is a discipline to govern the components that gets release into the mainstream base platform. The release process ensures proper change control and configuration management for the components within the base platform. Platform release is applicable to all home grown components as well as 3rd party implementations.

Activities: All/any activities obvious to the release process (as decided by the PDLC) will also be applicable to the core platform release process.

Artifacts: The input and output artifacts will be specific to the QA process as decided by the PDLC.

Key Note: One of the core output artifacts for technology release is the ConfigMap updates of the base platform. Also relevant release notes and risks must be part of the output artifacts. The ConfigMap and risks list will be primary input artifacts for the “technology life-cycle management” discipline.

8. Technology Lifecycle Management

Technology lifecycle management is a discipline in which the base platform and technologies are serviced and maintained throughout the lifecycle of the related components. During lifecycle management, it becomes necessary to identify the primary owner of the relevant technology component throughout the lifecycle of the component. The lifecycle can be broadly broken down into the following three phases:

8.1) Technology Establishment
8.2) Technology Sustenance
8.3) Technology Sunsetting

8.1) Establishment : Within the establishment phase, one need to ensure that all the relevant documents, binaries, source and related artifacts are made available for the appropriate groups (engineering, PSG or partners) to perform business as usual. Typically, developer education activity (walkthroughs, workshops or simple white boarding) is the core concern during the establishment phase.

During this phase, the component that got released into the base platform will encounter a lot of hiccups when engineers and developers start using them for the first time within the product. Even though a comprehensive QA would have been performed on the components, there will probably be some good number of issues and bugs raised by engineers/developers. The primary focus while planning the establishment should be to ensure that the owners of the released components are dedicating there time for smoother inception of the components in any functional/application projects.

During this phase, it is important to establish a strict change management process for any changes requested by the developer community. It may not be necessary to implement all changes into the components immediately. Instead due diligence must be enforced only to feedback critical change request that were overseen during the development life-cycle of the component. Consolidated changes (after analysis) must be routed through further activities of the technology management process block.

Note: Lifecycle management is a sub-process/activity of the Technology Management discipline

Typically the establishment phase would last until the first core product release including the related technology components is made. Generally tag promotions must be used to identify the status of technology components. Mostly the end of establishment phase would promote the components to “production ready” or “established”.

8.2) Sustenance : The sustenance phase of the technology lifecycle is post establishment activity. The primary focus of the sustenance phase is to ensure continued maintenance of the components that were established into the product. Some of the core activities during the sustenance phase can be as follows:

• Timely resolutions of external bugs (customer bugs)
• External supplementary requirements gathering (Scalability, Performance, Extensibility, Usability, Configurability)
• Identify component enhancements
• Due diligence on CRs (Change requests)
• Consolidation and categorization of CRs, enhancements and other requirements for next version of component.
• Component version and release planning
• Inputs for component EOL (End-of-life) analysis

There can be multiple minor releases during sustenance but a major release must be fed back through the activities of technology management. Major releases should come through the technology process lifecycle. Deviations of the technology architecture process are quite possible in these scenarios.

8.3) Sunsetting : The sun setting phase is a phase within which the components who’s EOL (End-Of-Life) been identified is eventually phased out of the product. This phase contains the most critical activities which ensure a smoother transition for the product during the component sunset.

The requirements build-up for what components needs to be identified for EOL, is part of the architecture roadmap management discipline. By that, what it means is that, the requirements can arise due to many factors or needs from any discipline, process, dimension or group, but the collection of these requirements and analyzing the requirements to objectively justify that the EOL is in fact necessary, will be part of architecture roadmap management.

The sun setting phase is an outcome of the decision already made during the roadmap management stage where EOL is tagged to the component. This phase will kick start further processes on how-to sunset the components. The what-next after sunset must be already identified during architecture roadmap management.