InfoWorld Archives - Page 2 of 3

5 Approaches to lower enterprise technology costs

July 10, 2018March 4, 2024Scott S NelsonLeave a comment

At the same time that everyone is talking about digital transformations there is demand from the boardroom to lower spending on technology. On the surface, these two goals appear to be mutually exclusive. How can innovation and transformation be carried out with a reduced budget? Here are some approaches that can help resolve the paradox.

Create a contract between business and IT

Everyone agrees that IT and Business must work together to improve operational efficiency and profitability. If you only read business-focused or technology-focused publications, you probably thing everyone is doing this and wonder what is wrong in your organization where you are not seeing the benefits of such cooperation. One reason for this perceptual disconnect is that in many organizations only one side of the equation considers they are working together. In actuality, that side is dictating capabilities to the other side and calling it cooperation. If there are frequent conversations in the enterprise about the same issues occurring over and over again, this is a good sign the cooperation is one-sided.

A contract spells out the responsibilities of both parties and details the necessary interactions that must occur to ensure those responsibilities can be met and the corrective measure to take when they are not. The contract between IT and Business will be unique in every organization with some common items included such as:

Both parties must be present when goals are finalized and that all goals have a clear definition of achievement.
The path to goals are steps, not leaps, and a cadence of interaction for the purpose of reviewing progress and refining expectations and understandings must be set before pursuit of the goal begins.

Double the project budgets

Sure, this is about cost-cutting, so how could doubling project budgets help that? Because two of the most common technology costs are the increase in spending as the project nears the scheduled completion date and the resources necessary to maintain an under-funded development effort in production. By doubling the budget up front inefficient uses of funding will be reduced or eliminated. Providing bonuses for coming in under budget coupled with adequate funding up front will both motivate and enable IT teams to reduce costs.

Leverage professional consulting services

Companies that reduce their consulting costs rarely see a corresponding reduction in overall IT spending. Yes, consultants cost more per hour. This is because they absorb the expenses of recruiting, training and managing highly-skilled specialists. This is not to disparage the recruiting, training and management capabilities within an organization. It is about the focus of those efforts. Within an enterprise, the highly-skilled are need for operations and tactical projects. If they are focused on strategic projects they will either not be able to properly perform maintenance or they will be rushed in their development efforts. Similarly, contracting individual resources to fill in the gaps on either side is a risk because the individual contractors are not used to working together as a team and are motivated to focus only on the short-term. The highest cost for consulting services is acquiring new business, which is a driver for the consultants to provide long-term value. Also, consulting companies have teams that deal with the new and strategic all the time and bring experience acquired from multiple enterprises.

The key to benefiting from consulting is to determine what your needs are up front and ask for references that can vouch for those capabilities. When considering your needs, do think about the ability to work across business and IT as well as skill and willingness to train your personnel in post-implementation maintenance. You should also understand that hiring a consultant is not like hiring a contractor. Where sourcing a contractor, seek out one with specific experience in your exact planned solution, consultants are experienced in dealing with early adoption and rapidly absorbing new technologies. The key thing your consulting partner needs to be experienced in is multiple solutions with similar technologies and challenges.

Promote from within

Another common theme in IT is the high cost of recruiting and dearth of qualified candidates. If (as an example) it costs $40,000 to recruit and train a new architect and the position turns over on average every three years, a $10,000 raise or bonus every year will still cost less and the architect will become increasingly more efficient within the organization as they have a deeper understanding of how things work.

Iterative road maps

The lure of going all in on new technologies, architectures and services is the same as that of playing the lottery or betting on a slot machine: the media and advertiser only show you pictures of the winners. Granted, the odds of succeeding within an enterprise though innovation are better than most gambles, but enterprise technology should be managed more like an investment portfolio than a gambling budget. Compare opportunities by their potential return. Balance your investments between levels of risk. Build on success and knowledge. In IT, this equates to doing a cost-benefit analysis on IT projects then staring with a proof-of-concept or pilot program and then only change existing assets when it is profitable or practical to do so.

Originally published at InfoWorld

Your poor MTTR isn’t a technical issue

February 6, 2018March 28, 2024Scott S NelsonLeave a comment

(Feature photo by Markus Spiske)

One of the biggest misconceptions about troubleshooting systems is that it requires deep, specific technical knowledge to locate and solve production issues. This assumption can often result in extending the time between the discovery and resolution of a problem. At first this may seem counter intuitive, so let’s look at some common scenarios to see which concept is makes the most sense.

To start with, most assumptions about broad concepts are generally wrong because they are based on the expectation that there is a single, best doing things every time. There are certainly times when the developer of a particular solution can look at a problem a production application is having and instantly say “I know why that is happening”. This happens not because the developer deliberately left an issue but because most solutions have multiple, valid approaches. Some of them can have flaws that may not be immediately obvious. In some cases, all options have flaws and it is a matter of choosing the path with the weakness that is least likely to be found “in the wild”. The experienced developer will unconsciously be aware of these potential problems and, when presented with the issue in production, will instantly recognize it. In most cases these things will surface and be addressed in QA before they reach production. By the nature of production systems (where users are always more inventive than the best QA analyst), the application will encounter something that was not anticipated.

Once in production, the key to identifying the cause of the problem is to look at what is happening, where the person with deep, specific knowledge will most likely first look for what is expected to happen. There lies the trap. If a reasonable QA effort was put in before release, it is what is unexpected that is more likely to be the issue. The easiest way to find an issue that isn’t immediately obvious is to have no expectations and instead observe what the behavior is and trace it back to its origin with no anticipation of what will be found. It is much more about applying a way of thinking than it is about knowing something in advance to find the root cause.

There is also the psychological aspect that can occur in having the original developer investigate the issue. For reasons that could fill another article (if not a whole book), the first thing the developer tends to look for is something outside their application as the cause. It is quite possible it is something from outside causing the issue. The more experience the developer the more likely this is the case. In trouble-shooting, the goal is to fix the problem and having any assumptions at the start can delay finding the problem where ever it is. Yes, sometimes those intuitive assumptions are useful, so long as they are abandoned if they don’t quickly prove out.

When issue is determined to be outside the responsibility of the person or team investigating, the mistake most often made is to hand it off to another team before clearly understanding how the external system is causing the issue. Failure to articulate irrefutable evidence of the source of the issue before passing it on to those responsible for that part of the system to solve can result in an unproductive back and forth between developers or teams as they also expect it is not in their work.

Once the issue is identified, deep knowledge may still hinder resolution and will not always be necessary. I was recently asked to help with an issue where the production support team followed a recommendation from the cloud platform vendor support to address an issue with throttling by moving the offending process on premise in a hybrid solution. While platform support knows their platform really well, the myriad ways it can be implemented is just not possible to always anticipate how combinations will work out. The support team followed the advice without thinking about why that process was deployed to the cloud to begin with. The change resulted in new issues because there were insufficient resources in the on premise server. Further, when validating the change they only looked at the cloud monitoring (where the problem originally manifested). The failure point had been moved to the on premise system and it was the business that reported the new manifestation of the problem (and brought me in to help).

The final solution was to manage the iterations in the process being throttled to bring it within threshold limits. This required no knowledge of the cloud platform beyond that throttling was a factor, and no detailed knowledge of the specific implementation as the logs clearly pointed to where the failure was occurring which was the point where the counter needed to be added to avoid the threshold.

To sum up the lesson, the ability to suspend assumptions and ego are far more critical than specific technical knowledge to solve issues in production. During development it is common to be stuck for a while solving a bug and to ask someone else to look at the problem with a fresh perspective. Carrying this process on into production will resolve issues faster and leave more time for working on the next cool iteration.

(Originally published JAN 17, 2018 at InfoWorld as “Production system troubleshooting 101: it’s not always about technical knowledge”)

How Salesforce Supports Citizen Development

December 22, 2017March 11, 2023Scott S NelsonLeave a comment

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

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

Salesforce Community with Custom Objects in a Flow

November 27, 2017March 11, 2023Scott S NelsonLeave a comment

Last year I wrote about Revisiting the Question of Build versus Buy for Web Portal Solutions, which was greatly inspired by the reduction in solid portal offerings that began about a decade ago. The dearth in offerings is a result of acquisitions by vendors who prefer that portals work only (or, at least, easily) with their own products. While I’m not a big fan of architectures that lead to vendor lock-in, there are situations where the portal is focused on exposing a certain view of a specific application and it is best if that is built by the same vendor as the application itself. Case in point: Salesforce Community Cloud.

Salesforce has been rapidly improving their Community Cloud product with more features and easier management. I believe this is partly fueled by the demise of pure-play portals that can surface Salesforce functionality using the great Salesforce APIs (Liferay being the exception) and a smart move to increase Salesforce revenue while reducing customer costs for high API traffic. Whatever the drivers, I like where it is going. Though, like any technology on a rapid growth curve, there are some bumps along the way. One such bump is puzzling out all of the different permissions involved to provide various functionalities. Generally these bumps are easily overcome thanks to the active SFDC user community. Recently I ran across something that was not so easily solved and thought I would share it here.

The requirement is to create a workflow that ties together the standard Case object with a custom object. The goal is to make the user experience of working with a long form created previously to support the custom object by breaking down the numerous fields into user-friendly chunks that will result in a Case being created along with the custom object as a related object. With the normal amount of “oops” and “darns”, I managed to put together a Visual Work Flow that would take the inputs and create the Case object and then the related custom object.

A Visual Work Flow to take inputs and create a Case object and related custom object

I then created a Community page in a community using the Lightning Community template Napili and placed a Flow component with the new workflow configured.

Adding a Visual Workflow to a Lightning Community

The first bump I hit was that the Case failed to be created, which I easily figured out from the various Salesforce user communities was because I was using the wrong ID for the contact (the User ID is different than the Contact ID for community users). Once this was fixed, I then found that the custom object was not being created. Back to the trusty community posts where I found the sage advice to grant access to the object to the profile referenced in the Community Builder Settings. Well, not so sage as in my haste I forgot that that fields only applies to “guest” users, i.e., users not logged in.

To make a very long story short, the default profile granted to customer community users did not have permission to access the object (even though, during creation, I granted necessary access to all profiles) and the default profile is read-only. The fix was to clone the default community user profile, grant that profile the necessary permissions, and then use that profile for my community users. Who then could not log in! Oh, yes, even though everything about the default profile was cloned, the new profile still needed to be granted access to the community using the Community Administration view.

Granting access to a new profile in the Community Administration view.

And, finally, the workflow could flow to the end.

Lightning Community Workflow Complete View

Originally published at InfoWorld