I just came across a nice post from a Force.com developer on his blog, d3developer.com,  that touches on many of the concerns that are being felt throughout the salesforce.com partner and developer ecosystem regarding the company’s recent VMForce announcement.

Three key points:

(VMForce) raises the question of just who Salesforce is competing with.

Salesforce can no longer simply compete with Oracle business applications, can it realistically think to match Amazon or Google to be a leader in a PaaS (Platform as Service) race?

(Salesforce needs to) Articulate more clearly the gameplan to the developer community.

The Question Without an Answer

What exactly is “Cloud Computing?”  The term will probably never be fully fleshed out in terms of a common definition, and at the end of the day that’s fine with me. Yes, we need to put structure around the term and the industry, but as we noted earlier in the year with a post about cloud maturity models, we run the risk of painting ourselves into a corner if we try too hard to make things fit neatly into buckets that we can easily classify and categorize. Taxonomy will be key to understanding and adopting cloud computing, but I’ve become convinced that in order to truly embrace the cloud, we must…

Embrace the Abstract

I had the opportunity to speak at Interop Las Vegas this year with Rick Nucci of Boomi and R. “Ray” Wang of Forrester Research, and when I made the statement that “cloud computing is the technical manifestation of Service Oriented Architecture,” I realized that I had found the unifying principle of cloud-based solution design; unifying both in the sense that the promise of SOA finally has the technology behind it to transform it from philosophy to practical design pattern, as well as in the sense that the term “cloud computing” itself was being co-opted in much the same way that traditional software vendors co-opted the entire concept of Service Oriented Architecture to sell middleware throughout the decade.

Cloud computing may mean many things to many people, but in the end its full potential can only be realized if we stop trying to think of it in terms of the “known known” and embrace the the “known unknown.”  More importantly, when we think about the cloud and applying SOA design principles, we cannot continuously innovate and drive value if we are traversing connections inward to rationalize patterns and explain the abstract with the known; we must restructure our patterns and embrace the abstract in an attempt to forge new connections by moving outward beyond our comfort zones. The next generation of system design is less about creating code, and more about assembling services – innovation through extending value in what already exists rather than inventing new sources of value.  In terms of practical application, this means moving up the stack and…

Learning to Describe Rather Than Prescribe

An interesting pattern that I observed throughout 2009 is the continuing tendency to try and reinvent the wheel despite the fact that not only has the wheel already been invented, but it’s right in front of our eyes and meets our needs 99 times out of 100.  I saw this over and over with Salesforce CRM and Force.com projects; the value of using Platform-as-a-Service is that someone else (or more accurately, thousands of other people) has already thought about just about everything you could possibly need in a data model, user interface, and business rules.  And not only have they published just about everything you could possibly want in an easily configurable platform, they host it and manage all of the operational details such as backups, upgrades, and security. Yet time and again I encountered teams that thought that their way of doing things was better, and would go down the path of trying to build Salesforce on Salesforce before realizing that the same outcomes could have been achieved by spending a little more time upfront optimizing business processes and making minor configuration changes than going down the path of creating complex custom workflows, classes, and user interfaces to achieve the same end.

Some case studies are extreme, such as the support manager that duplicated Contacts across multiple accounts and assigned multiple portal logins to customers – in one extreme case 101 times – rather than setting up sharing rules properly; I don’t have to tell you what a data quality nightmare that ended up being.  In other cases, it’s simply a matter of building rather than reusing what’s already there, resulting in hard-coding of attributes and logic that should be dynamic and extensible.

What I’ve come to realize is that there is a conceptual barrier that we need to overcome when it comes to metadata and other abstracted entities; because multitenancy architecture and SOA are reaching such a pervasive state, we must shift our thinking to describe what already exists rather than trying to recreate it.  Entities exist once and in perpetuity – for example, there is only one of you in the entire world and you cannot be recreated on demand – thus our ability to provide context necessarily requires us to describe the entity in a manner that provides value to the application; the ability to describe entities with deep domain knowledge and create relationships to other entities that enrich the value of the data set will become an important competitive differentiator.

This will take time and a great deal of trial-and-error until we get it right, but in the end it is the only way to leverage the tremendous potential of core cloud computing architecture patterns; our entire concept of producing and consuming services has to change, which leads me to the conclusion that…

SaaS is Dead…Long Live SaaS

Granted, the title of this blog predicates from the acronym for Software-as-a-Service, but as cloud services mature and the traditional technology stack gets blown up and reassembled, the entire concept of “software” shifts from the self-contained, monolithic packaged application to that of a delivery framework. Software was invented to make hardware useful; hardware is abstracted in the cloud and we no longer write code down to the kernel level – we assemble, configure, and code to the layer of abstraction of the specific cloud platform.  The term “software” will gradually fade from our lexicon.

This was the philosophy that drove the Java language and multi-platform virtual machine concept, and will continue to evolve with next generation rich Internet application frameworks such as Adobe Flex / AIR.  What we will see moving forward is the continuing shift from desktop software that interacts with the cloud, to ubiquitous frameworks that consume data and logic services from the cloud and leverage the processing capacity of the local machine to enhance the user experience.

2009 and its economic and sociopolitical malaise are now behind us, and by all accounts 2010 will be the year of the cloud. While the technology and the terminology of the cloud have permeated the mainstream, it will take significant shifts in thought processes and design patterns before the cloud can be fully leveraged.  Here’s to a great New Year and the hopes that the likes of Microsoft and other relics will accelerate their fade into obscurity and stop trying to steer the cloud discussion back into a box.  Until next time, here are some…

Other 2009 Wrap-ups and 2010 Predictions

Jeff Kaplan: Key Challenges Facing Cloud Computing in 2010 and Beyond
Phil Wainewright: Tips from 2009 for a prosperous 2010
Dave Barry’s year in review: 2009 (Humorous, non-cloud related)

Michael W. Topalovich, CTO
Delivered Innovation

For years, the rallying cry for the CIO has been to align IT with “The Business.”  This presupposes that there is a wall between IT and other functions and processes within an organization, which of course we know to be the case. While nearly every business function that lives in its own silo has challenges integrating with other functions within the organization, IT has been particularly challenged because of the technology-centric reality of its world; while other functions may not necessarily have a direct impact on the value chain, IT is often viewed as being completely disconnected from it in many organizations.

Technology vendors have long targeted the CIO with messaging that implies an understanding of ITs alignment pain, and they have offered myriad remedies for closing the gap between IT and the underlying business processes that create value in an organization. Everything from enterprise applications to network management tools have promised to lead beleagured CIOs to the Shangri-La of “IT-Business-Alignment.”  Ironically, the technology with the most promise for bridging the IT-business divide has been right here under our noses, but only a relative handful of visionary organizations have embraced it to drive business value.

So if the technology is here, why haven’t the barriers between IT and value-creating business processes crumbled like the Berlin Wall?  The answer is simple: Technology without process is an empty proposition. Herein lies the key to bridging the divide between technology delivery and key business processes – stop viewing them as discrete entities. No single technology is going to magically run a business, and no business process can exist without technology. This is by no means a new idea, but in order to fully grasp the concept, one needs to embark on a journey of cognitive dissonance…forget everything you know about how IT and business have worked together in the past, because the traditional models of delivering technology services are dead.

Cloud computing presents a fundamental restructuring of the way technology services are delivered; in a way, cloud computing represents the technology manifestation of service-oriented design and delivery principles. Cloud computing does not create a bridge between technology and business processes – it goes far beyond that by obliterating the bridge and merging technology with process. The cloud computing service that best represents this unified technology and business process paradigm is the Force.com platform by salesforce.com.

By taking most of the variables out of the technology equation that have long been the domain of the CIO and the IT organization, Force.com gives those closest to business challenges the power to create their own situational solutions rapidly and effectively. This does not necessarily diminish the need for IT, as long as IT evolves to meet the challenges of managing the proliferation of cloud computing services throughout the organization; by undergoing a fundamental metamorphosis into a service and system management function that focuses on unlocking business value through governance and integration, IT can reinvent itself and retain its relevance within most organizations.

So what does this look like if IT is no longer the center of the corporate technology universe and business process owners have direct influence over the systems that enable the creation and optimization of value chains?  Simply stated, the role of the business analyst has just been elevated to the top of the system design and development hierarchy. Once relegated to the role of translating business requirements into pseudo-code and “throwing it over the fence” to a project manager or counterpart in the IT organization for further chunking and processing, the analyst has direct access to the technology systems and can implement or change functionality directly, providing immediate feedback and reducing cycle times dramatically.

Not to put too fine a point on this concept, but empowering those with the deepest of domain expertise to manage process-focused technology services and situational applications is game changing. Take a step back and look at a typical system development lifecycle process in a typical midsized or large organization:

1. A business need is identified within a functional area of the organization
2. The business need is validated by an analyst
3. A business case is developed to justify the cost and effort to engage the IT organization to design and implement a technology to address the business need
4. A business project manager is assigned to manage administrative overhead and the relationship with IT
5. An executive sponsor from the business function is assigned to provide leadership guidance and political capital to the effort
6. A business architect is engaged to design and integrate a functional solution with current business processes, independent of technology
7. The business analyst breaks down the architectural, functional, and feature requirements and writes a voluminous requirements document
8. The project manager initiates the process of engaging IT
9. IT tells the business project manager that it is too overwhelmed to take on any new projects
10. The business executive sponsor exerts political influence with a counterpart in the IT organization, and the project gets prioritization and traction
11. The business and IT project manager organize a project kickoff meeting that promises great fanfare and a pizza lunch
12. A clever name or acronym is assigned to the project
13. The business project manager presents the business case and the project requirements to IT
14. An IT analyst interprets the business requirements and translates them into IT-centric terminology
15. An IT architect takes the interpreted business and technology requirements and designs the network, server, platform, database, application, presentation, and security architectures for the proposed IT solution
16. The architect presents the solution architecture to the business stakeholders, and they nod their heads in polite agreement despite having little comprehension of what is being proposed
17. The architect engages functional architects to design the specific components of the proposed solution
18. IT project managers from each of the impacted functional areas are assigned to the project to manage Gantt charts and status reports
19. The IT project managers assemble teams of the appropriate technical subject matter experts, all of whom are currently assigned to a minimum of ten other projects and have little available focus or bandwidth
20. Internal IT project kickoff meetings are held, with pizza but slightly less bravado
21. After 6-9 months, if the entire effort has not died on the vine, a preliminary system is presented to the business for usability testing
22. The business stakeholders test the system and find that it bears little resemblance to what was originally envisioned
23. The entire project team is pulled into an all-day offsite meeting at a local hotel with catered snacks and delicious coffee to figure out what went wrong
24. It is determined that certain assumptions that were made at some point in the process were not valid, and the project regresses to mitigate the faulty decision logic
25. 15-18 months after the initial launch, the project is re-lauched with a clever new name and another pizza kickoff meeting, and the cycle is repeated until the project is either cancelled or a system is delivered that meets roughly 20% of the originial business requirements.

Now look at an analyst-driven situational development process, enabled by Force.com:

1. A business need is identified within a functional area of the organization
2. The business need is validated by an analyst
3. The analyst plans and designs a solution to address the business need
4. The analyst configures Salesforce or builds a custom Force.com app in a development instance of the platform
5. For any advanced design or development work, the analyst calls a trusted partner such as Delivered Innovation or SilverTree Systems to provide on-demand Force.com expertise
6. The analyst presents the new system to the business stakeholders
7. Having direct access to the new solution, business stakeholders provide instant feedback to the analyst, which is then incorporated into the solution design
8. This iterative process is repeated two or three times until the system is refined to the point where the business stakeholders are thrilled with the results
9. 6-8 weeks after the launch of the initiative, the new app is approved for production rollout, users are trained, and the business rapidly incorporates the new functionality into its processes
10. The business stakeholders take the analyst out for pizza to celebrate.

By empowering those closest to business challenges to create their own situational applications and solutions, organizations put themselves in a position of competitive strength by focusing on agility and rapid delivery of business outcomes rather than adhering to cumbersome and outdated technology implementation methodologies. Force.com and other cloud computing technology enables this transformation, and organizations that embrace this evolution and structure IT and business processes to leverage the game-changing potential of the cloud will find the rewards to be orders of magnitude beyond what was possible with traditional IT service delivery processes.

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?

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.