Posts tagged with «PaaS»

ebizQ Forum: What Are the Biggest Downsides to Cloud Computing?

Delivered Innovation CTO Michael Topalovich recently provided his take on the ebizQ Forum question: What Are the Biggest Downsides to Cloud Computing? From the Forum:

I’ll substitute “downsides” with “risks” because some of these may be viewed as half empty / half full arguments, but I see the biggest current risks as:

  1. Market confusion. As Peter mentioned, it is a mad dash to the cloud right now. And since nobody wants to feel left out, just about every company in the B2B tech space has re-branded itself as a cloud computing company. I’ve heard this referred to as “cloudwashing,” and the result is that companies will find it more difficult to find services specific to their needs, because of the tendency of providers to water down messaging into cloud buzzwords and ignore basic positioning and value statements.
  2. Cloud sprawl. With the rapid proliferation of cloud services, IT is struggling to adapt corporate service delivery strategies. The results that we have seen have included duplication and overlap of processes and functions due to services being provisioned directly by business units; loss of control of the billing for services because no single entity within the company is responsible for the procurement and management of them; and the equivalent of “shelfware,” a situation where cloud services are orphaned after the champion leaves the company or the business shifts focus.
  3. Lack of cohesive integration strategy. There is no doubt in my mind that the cloud model of service delivery is the one that we will adopt for at least the next 10-15 years of technology cycles, but until the integration of all of the pieces is thought through, the sum of the parts will never add up. My company has standardized our core service offerings around the Force.com platform from salesforce.com to provide the “glue” that holds all of the pieces together, and we “mash up” other cloud services into composite enterprise business systems through API integration, business process orchestration, and data integration using services such as Boomi. But if companies just provision cloud services for siloed requirements up and down the cloud stack (from infrastructure to SaaS), the disaggregation of these services will prove to be a value destroyer.

Read more

How Force.com Changes System & Software Testing Processes

It’s evident by this point that cloud computing technologies such as Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) have changed the way applications are developed. The interesting thing that we are finding with our customer engagements is that the rapid and iterative nature of designing and developing apps on Force.com has created an entirely new set of challenges with how the apps are tested prior to deployment to production environments. The ability to demonstrate application features and functionality to project stakeholders in near-real time is more of a double-edged sword than most people realize; on the one hand, being able to show progress and continuously incorporate feedback has fundamentally changed the concept of application development and delivery. On the other hand, if expectations are not managed properly, the ability to visually represent system designs and demonstrate prototypes in such a rapid timeframe could potentially trivialize the importance of testing, code refactoring and optimization, and change management.

With regards to the testing aspect of Force.com application development and delivery, I have observed some emerging patterns that warrant further study and discussion:

  1. Unit testing is real-time and automated. The Force.com IDE for the Eclipse SDK has been a solid development tool for some time, but the real-time feedback that you get using version 16.0 (Summer ‘09) of the IDE with the Eclipse Ganymede release (3.4.x) is of tremendous value. Granted, the Salesforce API will let you know if there is a problem with your code, but now we’re seeing potential issues called out in Eclipse prior to pushing code to Salesforce. If you think of unit testing in the traditional sense, where you are testing the validity of snippets of code, the very act of the Salesforce API accepting code that you push to the environment provides immediate validation in an intelligent and automated fashion. And with the line-item feedback provided by Eclipse, you can catch code validation issues long before saving to the server, significantly reducing the time required to track down and fix invalid code.
  2. Integration testing has combined with QA to become a metafunction. I will be the first to admit that I initially viewed the Apex 75% code coverage requirement imposed by salesforce.com as more of an annoyance than anything. Now I have come to see test classes not as a necessary evil in deploying apps to production environments, but as a tremendous opportunity to bundle elements of integration testing and end-to-end application QA into a single overarching process. While most developers dread having to write Apex test classes, we include them in our design specifications as a best practice. If you think about it, what we are doing is taking the use cases that are fleshed out during the design process and building out test cases from the onset of the development effort; this is a fundamental shift from the traditional role of QA in outdated waterfall-based methodologies that build and execute test cases and QA plans only after development, unit testing, and integration testing are completed. I have worked with far too many organizations where QA was considered an albatross – the development effort was complete for all intents and purposes, the finish line was in sight, and here comes QA adding weeks, if not months, to the Gantt chart right before that final milestone. By making QA an iterative process that is tightly integrated with development processes, there are no downside surprises at the end of the development cycle; QA is already done along with integration testing, and it can be argued that the most important aspect of this is that QA is no longer a discreet process – it becomes a living, breathing overlay of the entire development methodology, producing test classes that live alongside the production Apex classes.
  3. User Acceptance Testing is a combat sport. What we have found with many Delivered Innovation clients is that if a prototype meets functional requirements, it’s considered “good enough” at that point. The reality of the situation, 9 times out of 10, is that “good enough” is not quite good enough for a number of reasons. Namely, demonstrating a prototype in a controlled environment with use cases that are designed to show successful outcomes does not flesh out the true functional capabilities of the app; only when users start beating on an app do we start to see where the stress points are in the functioning of the application. This is why we encourage what we half-jokingly refer to as “break testing” – we encourage users to “break” the app by any reasonable means. Realistically, we want this to happen upfront and not two months after production deployment. Another reason why UAT becomes critically important in the testing process is because the execution of test classes is constrained by governors and limits far more conservative than production governors and limits. For example, while you can retrieve 10,000 records in a production (non-trigger) SOQL query, you are limited to 500 records when executing tests. While you may be able to write test classes that execute within governors and limits, once you release the app into the wild you just never know when Salesforce users will find the “unknown unkowns” and use the app in a way that could not have been anticipated…followed by the dreaded ‘Script Exception’ email alert showing up in your Inbox.

How has Force.com, or PaaS in general, impacted your testing and QA processes?

Read more

Excerpts from discussion with Jon Sapir on the impact Force.com has on IT service delivery

I tend to have very spirited philosophical discussions with Jon Sapir from Power in the Cloud / SilverTree Systems, and as much as he tries to get me to blog about some of this stuff, I tend to put it off indefinitely. Just came across this thread and thought there were some important thoughts to build off of:

The old / traditional approach had a lot more players involved…I always envision enterprise IT as two funnels connected at the most narrow point, with one funnel being IT and the other being “the business.” On the IT side, the fat part of the funnel is web programmers, platform programmers, DBA’s, etc.; the connection to the business side is the program manager, who takes specs from the business program manager and hands it off to a lead architect, who then disseminates pieces to platform / application / database architects, who then give specs to the relevant coders, who are then checked by a parallel QA organization that is segmented similarly by function. On the business side, the program manager is connected with a business process architect who assembles requirements from lead business analysts representing the business functions involved with the system, who then fan out to all of the end users of the specific functions / departments to gather feature / function / interface requirements / feedback. And scattered throughout is about a dozen project managers, each running their own project schedule for their piece of the world.

Force.com disconnects the business users from the stack, eliminating the direct involvement of IT and changing IT’s role to one of data / process governance + management. In some organizations IT may still provide the programmer, but in many cases the business architect will directly design the system, and the analysts will configure the system to the specific needs of their constituents.

The future piece further abstracts the business from IT, pushing governance to the periphery of the business where it is managed by analysts and designed by the business architect to overlay horizontal, end-to-end processes rather than a vertical / function-driven organizational structure. IT may provide technical services, but the internal IT organization, for all intents and purposes, is just one of many service providers that the business provisions IT services from. In the most likely scenario, IT manages the connectivity to the cloud, data/information security policies and overall governance, and potentially manages the service delivery / financial relationships with cloud providers.

Does this sound like a reasonable description of most enterprise service delivery processes? Is management and governance the role that IT will take on? Will IT simply become a service provisioned directly by business process owners? Does SaaS / PaaS / cloud computing really make such a significant impact on organizational and business process structure? For every answer we come up with, there are about five new questions.

Read more

Interop Panel Discussion Preview: Honeymoon and Divorce: Changing SaaS Providers

Interop is here, and based on the preparatory discussions that I’ve had with fellow panelists on the ‘Honeymoon and Divorce: Changing SaaS Providers‘ session, I am excited about the topics we will be covering and the insight that Jerry Smith (Symphony Services), Rick Nucci (Boomi), and R “Ray” Wang (Forrester) will be bringing to the table. I will be approaching the topic of migrating both data and SaaS code / logic from PaaS providers with a service-oriented mindset, giving real world examples of migrating applications from the now-defunct Coghead platform to the Force.com platform by salesforce.com. Delivered Innovation migrated both customer apps and our own strategic marketing suite of applications to Force.com over a period of several months with great success. I am confident that the panel will provide a great deal of value to attendees, as the topic of SaaS / PaaS “lock-in” is becoming more relevant with the proliferation of cloud computing services.

Please stop by if you are attending Interop. We’re scheduled to present at 4:00PM on Tuesday, May 19 in “Breakers L” at the Mandalay Bay conference center. I will also be attending CloudCamp this evening, let’s talk about ‘The Cloud’ over beers.

Read more

Jonathan Sapir: Situational Application Platforms Threaten Smug Programmers

Jonathan takes a somewhat provocative approach to pointing out that cloud computing and situational applications are rendering “traditional” programmers obsolete at an increasing rate. Derrick Harris at GigaOm lays out a similar scenario for those on the IT infrastructure side of the house as cloud computing pervades mainstream Corporate America. Both of these posts remind me of something that I had written early last year, “Platform as a Service and the Implications for IT,” just prior to transforming our business to focus on SaaS design and strategy.

There are compelling arguments on both sides that innovative technologies either create jobs or eliminate them, but I don’t think the discussion is that cut and dried. What’s inevitable is that cloud computing will certainly change jobs, and I think the bigger point here is that if you are an IT professional, if you have not learned by now that you have to continuously stay on top of new technology and business innovations to maintain your place in the pecking order, you will inevitably be left behind. Sure you can sit back and hope that Black Swan events such as Y2K will come out of nowhere and suddenly make your 20-year-old programming skills a hot commodity, but the more prudent approach is to evolve with the times and stay relevant. Cloud computing is here, so those hoping it would just go away are in for a rude awakening.

Jonathan Sapir: Situational Application Platforms Threaten Smug Programmers

Read more

Don Sears: SaaS Startup Failure Leads to Blog Banter

Don provides insightful analysis into the Coghead post mortem that I wrote last week. He touches on the issues that I had to think about prior to writing that piece, which has generated an astounding amount of traffic. His point about the decision to put all of Delivered Innovation’s eggs in the Coghead basket is a good one, and thankfully we didn’t wait too long to mitigate that risk by forging a relationship with salesforce.com. Takeaway - social media creates some interesting lines that you have to think about before you cross them, although hopefully Don realizes that this wasn’t a customer we were talking about here and the nearly 50 other posts on this blog are related to SaaS / PaaS advocacy and trying to forge the right path moving forward for our customers and peers, so the analogy he presents was somewhat fallacious. Beyond that, I appreciate the feedback.

Michael Topalovich

Don Sears: SaaS Startup Failure Leads to Blog Banter

Read more