How Salesforce Supports Citizen Development

Citizen development is really a responsible response to the dilemmas created by Shadow IT. Now that technology is available to those with minimal technical knowledge business users will implement solutions without the help of the IT department. The best thing IT can do about this is mentor the business users in ways that will support what business is going to do anyway in a way that will not lead to enterprise-level headaches. Salesforce is at the forefront in helping business and IT with this new paradigm.

The number of times I revised the title of this post is a sign of the times in technology. Those not steeped in the gray arts of technology may think that since computers process 1’s and 0’s that going from thought waves to software is a linear and clearly defined path. The more the technology evolves the less true that is. I started with the title of “How Salesforce Enables Citizen Development”, but a key premise of this post is that it is not a check box in the system administrator’s console, which the term “enables” insinuates. “Citizen Development with Salesforce” was considered and rejected because it has a tone that suggests that there is no longer a need for highly trained Salesforce administrators, architects and developers. Not only do I disagree with that premise, I more emphatically caution against the invalid assumption that such a void would result in cost savings. These nuances of title may seem like a lot of over-thinking except that as both a writer and reader I am all-too-aware of the tendency to base a fully formed opinion on the title alone.

I was recently asked to sum up the benefits of citizen development and came up with the following:

  • User-owned Solutions
  • Reduced IT Bottlenecks
  • Streamlined Process
  • Lower Costs to Deliver

Salesforce supports citizen development by providing a platform with capabilities that can be accessed and utilized with a minimum of training and experience. The unbridled optimist will look at the preceding sentence and imagine a world where every business user can build applications that are easy to use and will contribute to productivity at a lower cost.

Citizen Development Bumper Sticker Policies
Citizen Development Bumper Sticker Policies

The realist would (and should) take umbrage with the word “every”. Putting aside the variance in individual capabilities, there are other key factors that make “every business user” a dangerous assumption. Two key factors are time and inclination. It takes both to perform any one of the following critical tasks for a successful application:  Determine the full range of business requirements an application should address; analyze the variety of technical solutions and appropriately select the best fit for the requirements;  review the existing functionality within the organization for potential reuse and impact; train and support other users in the resulting application; and maintain proper data governance to ensure both adequate security and cost controls.

So, perhaps a better statement of how Salesforce supports citizen development would be “Salesforce provides the tools for an enterprise to enable business users to build applications with little or no IT support when proper governance processes are established and followed”. This phrase doesn’t fit on a bumper sticker as easily as “Clicks not code”. Perhaps “IT doesn’t go away. IT gets out of the way” almost fits, though.

The “lower cost to deliver” benefit is based on the streamlined process of citizen development, i.e., no need for business to create a full specification to hand off to IT for implementation since business will own the development. In an enterprise where the IT team is continuously backed up, this will lead to faster time to delivery as well. In cases where the scenario is simple or common enough to be configured in a generic manner, a great deal of time can be saved. However, this should not be confused with the false assumption that configuration over coding is inherently faster. Sometimes it is and sometimes it is not. Declarative programming must be provided in a way that is maintainable by the vendor and generic for the customer. For a skilled developer, custom development can be completed in far less time than it takes to configure a collection of generic options to something as simple as loop through a specific set of data looking for a specific output.

If it sounds like citizen development is a bad idea that is neither the case nor the intention. Application development is like raising a child… it takes a village with each member contributing their specialty at the best time and in the appropriate context. A governance group to provide guidelines, consider exceptions and enforce adherence; Architecture and security specialists to determine the best way to ensure compliance; Developers to provide reusable components when they are not readily available from the App Exchange; Trained Salesforce system administrators to enable appropriate permissions, configure necessary integrations, and manage production deployments.

In short, all of the roles that an organization following best practices for platform use will have in place anyway. On the one hand, supporting citizen development adds some additional tasks to those who support the platform. On the other hand, properly supported citizen development frees up platform support personnel to better focus on the tasks that most need their skills while improving relations between business and IT by enabling business to more self-supporting.

Originally published at InfoWorld

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Revisiting the Question of Build versus Buy for Web Portal Solutions

The general wisdom stated in the architectural principles of many an enterprise is “Buy before build”.  This often makes sense since the cost of a COTS license will be lower than the labor expense required to develop the same functionality in-house. There is also the peace of mind that a reputable vendor will own the maintenance of the system core.

Portals may be challenging this general wisdom.

View from the Outside

Putting aside the myriad of capabilities packaged into the common portal product (though we will come back to them later), the essence of a portal when the business looks at the bottom-line is the presentation layer of a web site. The technologies used in the presentation layer of web applications has been evolving the past several years at pace that is much faster than the average portal product release cycle. When the new versions are released, there is often signification re-work that must be done to upgrade or migrate. Because product vendors need to provide solid, dependable software, some of the included technology may already be out of date by the time it is placed in production.

To be clear, this is not to disparage portal product vendors. Anyone that has ever maintained a portal application much prefers having a thoroughly tested platform backed by 24/7 support when something goes wrong. There are trade-offs required to enjoy those benefits, though.

If being able to quickly put new UI approaches and technologies into production is a key business value in your enterprise, you will need to build rather than buy at least part of your portal platform.

Under the Hood

To compare the value of build vs buy vs customize it is useful to consider what buying gets you. What you get for your license dollar will vary greatly from vendor to vendor and even within a single vendor if they offer many options. To keep this from becoming book-length, let’s stick to the most common features available for the most common purposes and apply your own due-diligence to modify this list when examining your own platform selection.

Because terminology can vary greatly from one product to another, we will define these key, common features for the purpose of comparison.

Feature

Definition

Authentication Verify identity of the user
Authorization What the user is allowed to see or do
Personalization Behavior based on information about the user
Context-Based Navigation Site navigation driven by Authentication, Authorization and Personalization
Page Composition The arrangement of components on a page, sometimes influenced by Authentication, Authorization and Personalization
Content Integration Inclusion of managed content, sometimes influenced by Authentication, Authorization and Personalization
Release Promotion Moving features and functions from Development to Staging to Production

Working with the assumption that these are out of the box features, our comparison needs to consider if we need the feature and what it takes to create it ourselves.

Authentication

Every application server has some form of authentication mechanism, and all of the better application frameworks leverage the underlying server standards. While not the least important feature, it is the simplest to implement without a framework. In some cases, it is actually easier to do so.

Authorization

If you are authenticating against and LDAP, most application servers will have easy to use hooks into roles. Popular J2EE application servers have authorization APIs that are standards-based. Initially this may be a little more effort than Authorization, but if you document your approach and publish it internally where it is easily accessed, this should not be a major hurdle.

Personalization

Many development teams struggle with personalization even with a COTS framework where it is a prominent feature. In some cases where business requirements, developer training, product APIs and enterprise data architecture are misaligned, a custom approach may actually be easier. On the opposite end of the spectrum, when all of those factors are in alignment a vendor-provided solution is a major time saver.

Context-Based Navigation

This is often the most appreciated feature of a portal product. While at the UI layer the result is “show or not”, portal frameworks in concert with IDE and/or administration UI provide a rich set of features for coming to that simple Boolean result. Then again, products need to support a very broad set of circumstances in order to satisfy the most customers. You only need to implement those features that are part of your business requirements. In some cases, that will be a very simple implementation. In others you will learn why portal products are so popular. The key is to get very clear on your requirements and then design your solution to be flexible and maintainable.

Page Composition

This is a feature that all portals provide and would be very difficult to build from scratch with the same feature sets that vendor provide. However, very few organizations use all of those features. The complexity is around satisfying the requirements of all companies rather than just yours. If there is no need for runtime updates to page configurations there is no need for this feature. If the feature need is there, tightly managing the requirements and having technical and business stake holders working closely to review cost versus value will allow you to determine what is the best approach for your implementation.

Content Integration

Content management and portals have had a strange relationship dating back before there were any common standards for either. Some portals have content management features built in and some content management systems provide portal application features. Some have standards-based integration points and others simply recommend processes that allow the content to be re-used.

Release Promotion

What sets each vendor apart is how they implement the features. Each product has its own way of maintaining configuration and this results in either a specific tool or process to move that configuration from development to staging and production (plus any interim steps your enterprise happens to use). For solutions built in-house, you will need to define these processes or create these tools to provide the minimal disruption to services while making updates. If a vendor-provided product is sufficiently customized, an enterprise-specific approach may be needed, anyway.

Conclusion

So we see that we can create all of the functionality a portal provides without a portal product. The purpose of a framework is to provide commonly desirable features that are already built and integrated with each other, which is a key value portal products provide.

If all you need are these features, then standard wisdom of buy before build holds true. It still holds true if you can customize a standard offering in a way that is maintainable for you and supported by the vendor.

However, if you want something that is difficult to customize within a vendor-based solution or cannot be supported by the vendor (support-pricing is based on the product working as designed), then you need to weigh the value of that something[1] against building and maintaining it yourself. You may find that cost of ownership for the latest trend does not have an ROI to support following it and still go the out-of-the-box route.

Or you may go your own way and be the subject of the next web site trend-setter spotlight report.


[1] Here we are thinking about modern UI features, but the analysis holds true for anything you need that is of sufficient value

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Recovering Previous Versions from SharePoint

A few weeks ago I discovered that other people had mistakenly made changes to a draft of a technical document I was storing in SharePoint for which I had sole responsibility for. At the time we did not know how to access earlier versions of the document and I had to painstakingly review the entire draft and re-verify every detail.

Today I needed to compare revisions of a document that was stored in SharePoint with updates made on another machine. When I went to compare tab in this SharePoint managed document, I discovered how to find earlier versions!

Under the Review menu in Word, the Compare section has additional options for documents stored in SharePoint:

Compare Menu with SharePoint Library
Compare Menu with SharePoint Library

From here you can find the versions SharePoint has stored

SharePoint Library Revision Dialog
SharePoint Library Revision Dialog

And, once I knew what to look for, finding the Microsoft documentation was easy 🙂

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Thinking about Key Drivers to Architecture Approaches

For a solution architecture to be of utmost value it must address the target business capabilities in a manner that is maintainable, extensible and scalable. Solution Architectures follow unstated core drivers that influence the focus of the approach. The most common of these drivers are (in order): Initial Cost, Vendor Capability, Total Cost and Business Capabilities. These drivers are not mutually exclusive, and the key driver will be what each of the other drivers are weighed against in the solution. Each driver has value to the project and the enterprise as a whole.

In my opinion, Business Capabilities is the best key driver to have. Business Capabilities are what support growth and sustainability and contribute the most to the enterprise. The other drivers should not be completely sacrificed, but when they are given priority the result is frequently a gap between actual need and provided solution. They are driven by agendas that are secondary to the overall enterprise needs and better kept in the corresponding secondary priority.

This is not to say that every business capability requested by an individual or group is valuable to the enterprise as a whole. The business capabilities to focus energy and resources on need to be carefully chosen by the business, and once identified as a core need of the enterprise should take its place as the key driver.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

A Tale of Two Migrations

My first portal migration project was not originally expected to be a migration; it was scoped and planned as an upgrade. The expectation of an upgrade was well-founded given the high-level scope of moving from one version to the next. Those involved with WebLogic Portal at the time know the move from 7.x to 8.x was in fact a migration rather than an upgrade. While there were some bridge APIs to allow the use of old code it was poorly suited to anything that was even slightly customized, which is to say every implementation in production. The project had been expected to take 4 – 6 weeks with one developer and actually took 10 weeks and 2 developers. It was the first of two migration/upgrades for the same customer and the lessons learned from the first move allowed the second move to be completed in 3 weeks with a single developer.

Fast-forward a decade and enterprises with WebLogic Portal are once again faced with a migration. This time we know up front that it will be a migration and IT managers along with their business customers are hesitant to move forward without a clear path to follow. While the last ten years have seen all J2EE-based portal products move to standard APIs for their foundation, they still have unique frameworks that serve as (from the vendors point-of-view) market differentiator and (from the customers perspective) a new form of vendor lock-in. In the case of WebLogic Portal, the vendor remains the same (albeit through acquisition) yet there is still no easy way to switch to the newer version, and a risk to staying with the old as it has been feature-frozen since 2010 and is slated for “sustaining-only support”.

The migration path from WebLogic Portal (WLP) to WebCenter Portal (WCP) is unclear for many reasons. Perhaps the most common and least-realized barrier to an “automated” migration is that WLP in his current form has 10 years of layered patches and deprecated-yet-still-in-production APIs supporting features that are a broad amalgam of proprietary solutions and customized integrations with standard APIs fueled by a demanding customer base for a (relatively) small vendor where WCP’s current form is currently a little over 3 years old and managed by a company that believes in setting the standards and letting the market follow.

Another source of great confusion is the mixed messages over time and between messengers as to whether a staged migration is practical or if it must be done in either a parallel phase out or big bang approach. To make that even more confusing, all of those options are equally the “best” approach, though the true determination of the correct approach is specific to a combination of the enterprise time-to-market needs, development skill sets, ability to maintain multiple environments and maturity of the enterprise architecture.

Given all these contributors to the fear, uncertainty and doubt surrounding a move off of a long-lived portal platform to a new, unfamiliar technology landscape I am currently in the process of acting as guide down this winding path for a company where all the various factors pointed mostly in the direction of a staged migration.

Like that first move to WLP 8.x, the approach from the 20,000 foot elevation looked very simple and straight-forward. Build the header, footer and navigation components in WebCenter and consume all of the legacy WebLogic Portal-produced portlets over WSRP. Where the WLP application had a backing file at the desktop-level that assembled user and account information at log-in, the backing file would be modified for use at the portlet level and the rest would be easy-peasy. This original understanding was entirely correct except the last phrase, i.e., no easy-peasy.

To be continued…

References for Historical Release Dates

http://en.wikipedia.org/wiki/Oracle_WebLogic_Server

http://en.wikipedia.org/wiki/Oracle_WebCenter

Facebooktwitterredditlinkedinmail
© Scott S. Nelson