Counter arguments on attackers of SAAS!

Recently Information Week came out with an article that SAAS models were not always the best mode to go for enterprises to switch to cloud computing and the arguments that they gave basically were the following. I have marked them in italics and counter argued my point.

Not always cheaper. My colleague John Foley writes how San Jose CIO Steve Ferguson ran the numbers and found his creaky Outlook/Office 2003 costs $1.88 per user per month, compared with about $3 he'd expect to pay for Google Apps. Our recent outsourcing survey finds most people like SaaS and cloud computing: 37% say they perform better at lower cost. But 18% say they perform better at a higher cost. That may be fine, but has any SaaS vendor given you that Cadillac sales pitch lately--that it's not cheaper but better? Even slightly cheaper might not be enough, given the potential compliance and vendor viability risks.

Agreed they are not always cheap and in many scenarios and can become costly if based on per user model but the author ignores the long term return on investments by adopting cloud computing and SAAS models .Upfront implementation costs may be on the higher side but the internet and web give unlimited opportunity to increase your user base, increased user base means more exposure, more revenue, and the ratios normally leaning more favorably to the client side that implements cloud services. One shouldn’t forget the need for business’s today is accessibility of information on both sides of the quadrant be it internally within the organization or externally satisfying customer requirements. Desktop computing and desktop applications provide a bottleneck in the speed of operations.

Every app doesn't fit the SaaS model. There's a bunch of applications that CIOs just aren't thinking about converting to services, such as graphics-intensive apps like computer-aided design and many financial and transactional apps, which tend to be latency-sensitive and hold data that companies prefer to keep on premises. It might seem like every up-and-coming software category is a shoo-in for SaaS, but consider iRise, a growth company that provides application development visualization software--and has no plans for SaaS. Oracle sold $1.7 billion worth of good ol' software licenses last quarter. Microsoft's new Office 2010 includes a substantial Web element, but the core pitch for this multibillion-dollar franchise is still around the client software. In our survey, 39% of companies not using SaaS say there's no business requirement for it. On-premises software is far from a legacy concept.

Again the argument is weak not all business organizations out there are graphic or design focused as these companies fall under specialized service oriented firms whose needs are different.  The business’s that do not recognize the need will fall behind just as Microsoft was slow in catching up on the internet race. Survey respondents saying there is no need haven’t really assessed the environment needs correctly or asked how better serve the customer and more importantly have not asked the question how fast are their latency times reduced in serving those customers.

Security. SaaS vendors get that their existence hinges on rock-solid security. But they're also a bigger target--banks need guards cuz da crooks know da money's there. Our survey finds 39% of companies not using SaaS cite security as the biggest reason (tied with no business requirement as the most-often cited). This one will never entirely go away.

Vulnerability levels are a concern but the same has always been true for desktop applications since the last three decades, a worm can be released to crash any desktop application. A good SAAS model will not only have an advantage of better encryption and security features but it will also be the right venue to offer distributed computing which will synch data back and forth with client and Server applications.

Governance. It's different from security. Even people who trust a SaaS vendor's security might pass for compliance reasons. For example, Global Crossing, a user of Microsoft SharePoint and Exchange for collaboration, doesn't consider SaaS versions because, as a foreign-owned company that has contracts with the U.S. government, it faces a maze of data-handling rules best met on premises. Recruiting firm Manpower, a big customer of Salesforce.com with strong faith in its security, keeps some of its most sensitive client data in-house because of internal governance rules, says CIO Denis Edwards. It will get interesting when companies try to keep the sensitive data on premises while tapping online services to interact with that data to create the end-user experience they want.

One of my favorite topics to address and my comment here is good Governance and Governance practices are as good as their implementers are. Regulations can be followed but the idea is to be flexible enough that you can react to market needs and market conditions and comply with those frameworks and regulations be it for a full fledged SAAS enterprise application or a traditional organization with no big computing needs.

SaaS is winning a lot these days. But it won't win 'em all.

The only point I completely agree with which the authors finally state the obvious making their whole argument weak. The age of true networking has arrived, and its going to stay. The World is Flat and a little bit closer.

My counter arguing rants for the day.

Sam Kurien

Every Employee As a 'Business Analyst'

Business Analysis along with operational research have always been fascinating subjects to me. I have been lucky to have been part of requirement analysis for projects that need translation of business needs to geek for business process (BP) implementation. Business analysis provides a foundational stone of building especially when new changes are implemented in business processes, initiation of new projects or while making paradigm shifts in operational management. When an organization goes through these changes the tools sets in the BA's life becomes a combination of skills and behaviors he or she has developed over the course of years in terms of modelling, systemic thinking, inter-personal communication, root cause analysis, and general analytical skills. Keep in mind however, the end result in whatever way these skills are employed by the BA, the end objective is to improve and make the business better.

Using prototypes and models have long been and become the life source of rich communication for a business analyst. Modelling and UI designs especially help in reducing vital mistakes, understanding of bottlenecks and capturing of information from the end users that may have been missed. It gives the analyst the understanding of what people do, not what they say they are doing to make BP more optimal. So it boils down to communication and cultural.

Communication within the organization and between vendors/partners though crucial and a BA is a bridging gap being the assigned professionals who does full time business analysis a cultural change from the top down to treat every employee as BA has even greater merits. This means employees who are empowered to be a process improver's or be a  generator of ideas to improve BP's will ultimately help those project leaders and professional BA's to do their jobs more effectively and efficiently. Business analysis is after all ....the art of improving the business and every employee when treated as a professional with job descriptions filled in with details of improving process's, the end result is an ever evolving organization that is optimized to take advantage of the opportunities that come up in the market place. A culture like this discovers the business policies re-visits, re-evaluates and reforms these policies from time to time.

My thoughts till the next time,

Sam Kurien

Is Agile Project Management even an an appropriate term?

To give you a break from my silverlight and WPF babbling I will branch out occasionally into different topics to keep you interested and at the same time tone down my boredom from talking about the same topics again an again.  As the title suggests lets explore if "Agile Project Management" is even an right term that is being so loosely used these days.. To understand we need to first answer what Agile software development is?.

Agile software development has it roots in OOP (object oriented programming) where iterative development, use of a particular functionality could be reproduced, ability to plug in cross-functionally or design development methods for re usability of components could be done in an easily gave rise to the practices of agile software development into being.  This was extended across development teams for collaborative purposes during development or the life cycle of the project. Agile software methods break tasks into small increments and avoid long term planning, time frames are shrunk to a max of four weeks for a set of tasks to be completed which may involved requirement analysis, design, coding, testing and acceptance of that stage. Documentation is produced all along with those activities happening in tandem.

Usually in an agile software development team members usually come from cross-functional expertise and because hierarchal power structures aren't present decisions are made quick and responsibilities are assigned for development, changes, bug fixes, and releases. The team's size can vary from five to ten people but larger projects are usually comprised of such teams collaborating in real time and often Agile software development  then becomes a daunting and challenging task. However these days we have measurement metric softwares that measure the progress of each task on each day by which Agile development becomes easier. So coming back to the question I posed to mix the terms Project Management (PMP) and Agile Project Management wouldn't be right as they both address management of software development life cycles differently, they have different methods and practices. Traditionally Project management adopts the 7 step or waterfall approach the Agile software development uses methods like Agile Unifed Process (AUP), Agile Modeling, Agile Data Method, Scrum, Extreme Programming and while its practices consists of Test Driven Development (TDD), Behavior Driven Development (BDD), Pair Programming and the RITE method. I may explain each of these methods or practices some time in the near future.

I am sleepy now...some more about this in the far future.

Sam Kurien