• Smart SOA Award – Summa was acknowledged for the SOA integration work performed at various clients utilizing WebSphere Message Broker and WebSphere Enterprise Service Bus solutions.

• Smarter Decision Management Award – This award recognizes the decision management rules work that Summa has performed using rules technologies to solve complex business problems.

• Impact Best of Show – Summa demonstrated the BodyMedia FIT coach solution running on IBM WebSphere Optimization Decision Management rules software.

It was an exciting and exhausting week full of educational sessions, meetings and networking. Summa participated in four technology and business breakout sessions: we co-presented with two of our customers discussing decision management solutions, we took part in a panel discussing BPM technologies in Healthcare, and we led a session on how WebSphere Message Broker is being used to connect Microsoft .NET SaaS applications. It was a great week!

©2012 Summa Blog. All Rights Reserved.

If you have worked with JqGrid before you will no doubt be familiar with the default parameters passed to any ajax request: “page”, “rows”, “sidx”, “sord”. As mentioned above, these parameters correspond to current page, records per page, sort column, and sort order respectively. The grid passes these parameters with every user interaction so that the server can respond with updated data. For example, if a user clicks a sortable column or changes the number of rows per page then the grid will make an ajax request sending in the updated parameter values.

With MVC model binding it is relatively easy to receive these values as four string parameters on our action method. The DefaultModelBinder will locate them and match them by name to the parameter names in our method. So we could end up with an action method signature similar to this:

public ActionResult GetJqGridData(string page, string rows, string sidx, string sord)

This is a good starting point and does highlight how well the DefaultModelBinder abstracts away request variables. We do not need to specify if these parameters are contained within the url structure, the query string, or the posted form. However, with a little configuration we can make this signature look much cleaner.

Let’s start by creating a class to model the data we receive from the grid. We’ll call the class JqGridArgs and provide public properties for each of the four data parameters. Here is what this class could look like:

public class JqGridArgs
{
public string Page { get; set; }
public string PageSize { get; set; }
public string SortColumn { get; set; }
public GridSortOrder SortOrder { get; set; }
}


There are a few things to notice in the above class example. Our property names do not exactly match the default JqGrid names. Our first three properties are declared as strings, but the SortOrder property is declared as a custom Enum. This is not a requirement, but simply provides some additional type safety. The enum, which is not shown, only declares two members with names of Asc and Desc representing ascending and descending respectively.

Our goal at this point is to replace our cluttered method signature above with a cleaner version that accepts our new JqGridArgs class as a single parameter. Luckily we are not very far off from making this happen.

As it stands now, our main problem is that we have a mismatch between the arguments the grid sends (page, rows, sidx, sord) and the property names in our new class (Page, PageSize, SortColumn, SortOrder). The DefaultModelBinder will be able to map Page correctly, but the other three will fail. One option would be to create our own custom model binder to handle this scenario. MVC provides the extensibility to do this, but luckily JqGrid makes it even easier.

The setup call to JqGrid provides numerous options, one of which allows you to specify the parameter names for the ajax requests. In our example, we simply need to tell the grid to use our parameter names instead of the default names. This allows us to rely on the DefaultModelBinder in MVC to handle all of the mappings for us. Here is a snippet of what this setup looks like:

$('#myGrid').jqGrid({prmNames:{rows:'pageSize', sort:'sortColumn', order:'sortOrder'}})

Now we can update our original method signature to contain one nicely defined object instead of four disjointed strings:

public ActionResult GetJqGridData(JqGridArgs gridArgs)

This implementation definitely isn’t ground breaking, but it does provide a nice foundation. The class we created can serve as a base class for all of our grids. If necessary we can even inherit this class and append additional properties to match custom data being sent from the grid — in the postData array for example. Check out the documentation for JqGrid and please feel free to let us know your tips for this great plugin!

©2012 Summa Blog. All Rights Reserved.

To boost productivity, our team decided to use Mercurial to manage our development.  Among all the benefits that Mercurial could offer, two stood out to us if we ran our own Mercurial repo:

1. The distributive nature of Hg allows us to make local commits (and revert them back if needed) when offline or offsite; and
2. The flexibility of managing our own feature branches and CI integration without affecting the client or requiring client admin support.

You may find different reasons for running a slave repository, but we found such need quite common among our project teams.

A critical challenge of running a slave Hg repo outside the SVN master is how changes can flow back and forth smoothly and correctly.  It goes without saying that our bottom line was to not introduce errors into the client’s SVN code base, be it missed revisions, merge errors, or improperly recorded merge history.  After some trial and error, we arrived at a rebase strategy that we could confidently execute repeatedly without introducing procedural errors.

The beginning of our journey is depicted in Figure 1. First we created an S1 branch off the SVN trunk to keep our changes. A copy of the S1 branch was then used in creating a Mercurial repository.

Figure 1. Initial creation of SVN branch and Hg repository

After the development had gone on for a while (both in SVN and in Hg), and it was time to rebase the Hg changes, the two repositories would look like Figure 2, where we assume that the Hg repo had been rebased at least once, and the last merge point in SVN was tagged M1.  The last merge point in Hg was also tagged.  (This is the general case so that the rebase procedure described below can be applied repeatedly. For the first rebase effort after the creation of the Hg repo, the M1 tag would just be the root of the S1 branch in SVN, and the last Hg merge point the initial Hg revision.)  In Figure 2, the head of the S1 branch contains the merge results of the M1 tag in SVN and the marked revision in Hg.  In both repositories, additional changes have been committed beyond the last merge points.

Figure 2. Statuses of two repositories at the beginning of a rebase session

Below is the rebase procedure that we developed for rebasing the Hg changes to the head of the SVN trunk:

1. First create a new named branch, H1, in Hg to receive the changes from SVN.  This new branch should be created off the last Hg revision where rebasing took place as shown in Figure 3.  Depending on how often rebasing is carried out, the branch point of H1 could be many revisions back from the head of the default branch, but this is normal and necessary. It is important that we do not create the H1 branch off the head of the Hg default branch.  Doing so will cause all changes from SVN to be accepted as new changes and overwrite changes in Hg. Update the local Hg working directory to the H1 branch.
   

   Figure 3. Create a new branch in Hg to receive changes from SVN

2. Export SVN changes to the Hg working directory.  We will describe how to do this using TortoiseSVN.  If you are a hard-core command-line SVN user, you will have to come up with the equivalent SVN commands.
   • Create a new merge tag M2 off the head of the SVN trunk as shown in Figure 4.  In the TortoiseSVN repo browser, right-click on the M2 tag and select “Mark for Comparison” from the pop-up menu.  Next navigate to the last merge tag M1; right-click and select “Compare URLs.”  All the files that are different between M1 and M2 tags will be listed in a pop-up window1 titled “Changed Files.”  To extract changes correctly from SVN, it is very important that you select the new merge tag M2 for comparison first, because when you export the diff in the next step, the files from the first marked branch/tag will be exported.
     

     Figure 4. Create a new merge tag M2 in SVN and export changes between M1 and M2 to Hg

   • Select all files listed in the “Changed Files” window, right-click and select the “Export selection to” menu option.   Choose your local Hg working directory as the export destination.  After the export, you can examine one or two changed file to make sure that the exported files come from the M2 tag.  In Hg, commit the extracted SVN changes to the H1 branch.  It would be a good idea to include the two SVN merge tags in the Hg commit log message.  Now we have captured all the changes from the SVN master in one revision on the H1 branch in Hg.
3. Merge the SVN changes with the Hg default branch.  As shown in Figure 5, first update the Hg working directory to the head of the default branch, and then merge the head of the H1 branch, which contains the changes from SVN, with the local copy.  Resolve any merge conflict as we normally would and commit the merged code.  We should test the merged code and correct any merge errors as needed.  At this point, our code in Hg has been rebased to the SVN trunk at tag M2.
   

   Figure 5. Merge changes from SVN with the Hg default branch

4. (Optional) If merge history of the S1 branch in SVN is important, then we would want to perform a “pseudo-merge” so that SVN recognizes that trunk changes up to tag M2 has been merged into the S1 branch.  This “pseudo-merge” should be done before we move the merged code from Hg back to SVN.  We call this a pseudo-merge because the “real” merge was actually conducted and tested in Hg.  Without going into detail, merge the changes between the M1 and M2 tags onto a working copy of the S1 branch.  Conflict resolution in this case is not important (real merged code will come from Hg), for example, we could opt to take all local changes.  We could either commit immediately after the pseudo-merge, or wait until the Hg changes are overlaid in the next step.
   

   Figure 6. Conduct a "pseudo-merge" so that SVN recognizes the merge up to tag M2

5. Export the merged code from Hg back to the SVN branch.  First tag the merged and tested revision in Hg so that we know where we left off for the next rebase.  Next export an archive of the new Hg merge tag over a working copy of the S1 SVN branch.  This takes care of overlaying all the new and modified files over the SVN working copy.  However, for any file that was deleted in Hg, we will need to manually delete it from the SVN working copy.  This should not be difficult to do if we have a diff tool (which we did) that lets us easily compare two folder structures and see orphans on either side (Beyond Compare is such a tool).  One more thing to be careful about here is that Hg archive generates some Hg-specific files (such as “.hgtags”).  Make sure that these files are deleted from the SVN working copy and not get committed to SVN.  Now we can commit the Hg changes to the S1 branch in SVN.
   

   Figure 7. Export merged code from Hg back to S1 branch in SVN

We are done! (For a while, anyways.)  Our changes in Hg are rebased to SVN changes, and the merged code is exported from Hg back to our SVN branch.  Merge tags are created in both repositories and ready to be used for the next rebase effort.  And last but not least, SVN properly recognizes that our S1 branch has merged in the changes between the M1 and M2 tags.  This information will be useful when it comes time to merge the S1 branch back into the SVN trunk.

©2012 Summa Blog. All Rights Reserved.

Chatter’s Main Features

Customization – As we mentioned last week, Chatter gives the user the ability to cut through the clutter and noise surrounding your day to day activity and zero in on what meaningful and relevant to you. Chatter does this by providing highly customizable selections on what information you want to hear about, and how often. For example, your sales team is going to be very interested in the Opportunities that are in the pipeline. By enabling “Feed Tracking” for your Opportunities they will get notified in real time when updates are made to the Opportunities they’re following. Chatter also allows you to select which fields trigger feed updates. If you want the team to be notified whenever a Demo is scheduled, simply select that field. Chatter provides the flexibility to select which objects and fields to receive feeds for across your entire Salesforce instance: Leads, Accounts, Contacts, Opportunities – even Cases and Campaigns.

Follows – Like other social media tools, Chatter allows the user to select who and what to follow in order to get updates. First, you can follow your colleagues and receive feeds whenever they post updates to Chatter. It’s a great way to distribute information from subject matter experts and notices from your Senior Leadership Team. You can also follow individual records within Salesforce. By default Salesforce will have you follow any record that you own (this can be turned off, by the way). But if you want to see updates on a deal that a colleague owns, simply go to the Opportunity and click “Follow”. If you have insight that can help the deal along, you can post directly onto the feed – everyone following the Opportunity will receive your post.

Groups – Organizing your Chatter activity around Groups brings collaboration to a new level. “Groups” is one of the most powerful features of Chatter, and can be created instantly around any subject: Competition, Product Teams, Projects, Market Insight, etc. Members of a Group automatically receive feeds when other Group members make updates and posts. Say you have a large deal being worked with GenCom. As the Team working the deal post information about meetings and details, everyone on the Team can access the information in a centralized, searchable hub. Presentations, spreadsheets and documents can also be shared. Updates to any of these files will produce a feed update, alerting the team that a new version exists. Files can even be shared with your prospects and customers from within Chatter. If you want to deliver an agenda for an upcoming meeting on the large opportunity, a Chatter wizard creates a private website for the agenda, and sends a URL to the prospect. Everyone following the deal can see when the client has viewed the agenda.

Feeds – Chatter not only gives you the flexibility to select which Groups to join, and which people and records to follow, it allows you to select how often to receive your updates via email. For example, you can receive an update whenever someone mentions you in a post, comments on a post you made, or simply follows you. Chatter also aggregates these updates into Digests, which you can select to receive daily, weekly – or never.

How To Set Up Chatter In Less Than 30 Minutes

Using this information, let’s take a look at how you can quickly set up and deploy Chatter for your Salesforce users in less than 30 minutes:

Step One – Feed Tracking After enabling Chatter for your organization, select which objects and fields you want to trigger updates. In the screen grab below, we’ve enabled Feed Tracking for our Opportunities and checked the fields we think are relevant to Opportunity owners.

In our example, followers of an Opportunity will receive a feed update any time the “Stage” is changed. Users will see these updates on the record itself >>

and on their Chatter Home Page >>

Both places will show a running record of all of the updates for the records you’re following.

Step Two – Set Chatter Personal Email Settings Chatter fosters collaboration within your organization and provides lots of opportunities to connect with your colleagues. You can customize when you receive email updates on this interaction. For example, you may want to receive an email whenever someone comments on a post you’ve made on your profile. In the Personal Email Settings (shown below) you can select what type of interactions trigger these emails, or you can choose not to receive any Chatter emails at all.

As previously mentioned, you can also choose when to receive the Chatter Digest, which collects all of the emails you’re received and aggregates them into one email.

Step Three – Set Chatter Group Email Settings Chatter also allows you to select how often to receive posts and updates made by Group Members. As shown in the screen grab below, I will receive email notifications of every post made by Group members for Groups I’ve joined our will join.

And that’s it! In less than 30 minutes you’ve set you and your organization up for improved collaboration and efficiency. Chatter will peel away the unnecessary information and bring the conversation to the subject. You’re now better connected with your team members and more aware of relevant activity on all of your deals.

To learn more about Chatter and the Social Enterprise, contact Orion Wolff at orionw@summa-tech.com.

Next: Chatter deployment strategies

©2012 Summa Blog. All Rights Reserved.

The basic definition of governance includes: (1) definition of stakeholders and their roles and responsibilities; and the (2) process flow, encompassing rule authoring and change management. Thus, designing the governance model early in the implementation of a BRMS is a critical success factor. Make sure to allocate time and resources to completing this task in the beginning of the implementation. Consider the following guidelines in doing so:

• Define Goals. Know the purpose of the governance model. Before designing the model, clearly state the governance charter and goals – what the organization wishes to achieve with the model. This would guide how the governance process is formed and validate its completion.
• Reuse and Reach Out. Ensure that existing processes are not ignored and all the relevant user groups are involved with the governance definition. Some processes may be reused or redefined to suit the governance goals for your BRMS.
• Keep it Simple. Opt for the minimum number of participants and steps to the workflow as allowed by the organizational policies and regulations. With many changes being introduced by the system, making the governance model complex (e.g. to support different scenarios) could overwhelm the stakeholders. The model can change over time and be different for other rule based applications.
• Think Agile. Though it is important to keep the process simple, a single process may not fit all. Consider establishing a more agile process for low-risk, simple rule changes and maintaining existing software development processes for more high-risk, complex changes. Make sure all the stakeholders agree with the less involved version of the process.
• Have Checks and Balances. With the process being new to the business users and IT, each group may have doubts over themselves and each other. Incorporate testing and, perhaps, simulation into the process, as well as a mechanism to demonstrate that they have been completed. Also make sure that the governance model is able to provide evidence that the model is consistently executed.
• Continuous Integration. Revisit the model every time a new set of rules and business users are introduced to the system. Governance may change from one project to another, depending on available resources, the critical nature of the system, and the urgency in which the changes must be deployed to production.

Conclusion

According to the Gartner Hype Cycle, BRMS technologies would have to traverse the “Trough of Disillusionment” before reaching the “Plateau of Productivity”. But not all organizations need to undergo the disappointments before realizing the benefits of a business rule management system.

Reap the benefits of BRMS using the guidelines outlined in this blog series:

• De-mystify the benefits. Understand the benefits and limitations of a BRMS. Clarify what the system can offer with what the organization can support.
• Identify the need. Validate the need of the tool in the enterprise before getting caught up in the “hype”. Know the needs of the organization and how a BRMS can fulfill the requirements.
• Distinguish from similar technologies. Explore other decision management technologies and ensure that a BRMS is the right system for the organization.
• Determine enterprise readiness. Management, the LOB and IT must all be ready and prepared for the BRMS implementation. Agree on roles and responsibilities and commit to necessary organization changes.
• Implement in coordination. Balance the implementation between business users and IT. Increase the communication and coordination of the two groups to ensure success.
• Proceed with clear governance. Design the process for change management and monitoring of the BRMS. Share the governance model with the stakeholders and check for compliance.

Business rule management systems can undeniably benefit enterprises with real business problems associated with highly variable and complex decision logic. However, clouded with unrealistic expectations, confused by its true purpose, or plagued with improper planning and implementation, an enterprise can be disillusioned by its BRMS implementation. Ensure success by avoiding the common pitfalls outlined in the series.

References

Dixon, J., & Jones, T. (2011, July 25) Hype Cycle for Business Process Management, 2011.

Gartner. (n.d.). Gartner Hype Cycle. Retrieved February 21, 2011, from Gartner: http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

©2012 Summa Blog. All Rights Reserved.

The idea that the brain can do two things simultaneously has been myth busted. Instead, we’ve learned that we have a serial processor running in our craniums, and although it may be deft enough to provide the illusion of multitasking, on the inside it’s just an executive controller quickly switching back and forth from one task to another.

But is there anything wrong with an illusion, if the result is the same?

Well, yes. The problem is that there’s a cost to this context switching. A big one. For starters, studies have shown that we are actually less productive overall while multitasking, and make significantly more mistakes. In addition, multitasking also inhibits learning, lowers IQ, and increases stress. And as though that wasn’t enough, it turns out the more we multitask, the worse we are at it. Whew.

Despite all we know about the problems and perils of multi-tasking, however, the possibility of unitasking in the modern software development organization looks bleaker than ever. Cramped or open office environments increase the possibility for disruptions from our physical surroundings, and the ubiquity of social networking technology (e.g. email, text, instant message, Facebook, etc.) invite interruptions from beyond.

What’s more, within the world of software development, there’s a strong trend toward agile techniques, which value above almost all else communication and continuous feedback. More interruptions!

Now it might seem at this point like I’m a luddite, a social recluse, or (gasp!) a waterfall advocate, but in fact it’s just the opposite. I’ve seen first hand the benefits of both Agile processes and new tools for communication, it’s just that I think (in some environments more than others) we might take it too far. Responsiveness is important, but as the science of multitasking shows, there’s such a thing as over-communication. For the sake of our productivity, our sanity, and the quality of what we’re building, at some point we need to tune out the world, sink into a state of concentration, and get some freaking work done. But how?

Pomodoro

The time management practice of Pomodoro seems to be getting more attention lately, especially within the Agile community. The idea is simple: set a clock for 25 minutes and allow yourself to work on one task, uninterrupted. At the end of the Pomodoro, you get a quick break, and then you start again. If something pops up during the Pomodoro (an email from a colleague, a phone call from the product owner, etc.) you’re advised to record it and get back to it when the 25 minutes are up. Sounds great, right?

In my experience, it’s not so easy. If a business owner pays you a visit from 2 floors up about a bug in the application, he may not be happy when you ask him to wait 17 minutes until you’re done with your “Pomodoro”. Basically, the world doesn’t hinge on your stop watch.

Even if it did, without knowing when you start or stop the clock, it’s impossible for a colleague to know when it’s appropriate to interrupt and when it’s not. Depending on the size/activity of a team, a half dozen interruptions (of different forms) are easily possible within a 25 minute span. Just acknowledging these is enough to lose concentration.

Lastly, if each developer is on his own Pomodoro cycle, you could easily (albeit absurdly!) reach a deadlock. Joe pings Bill during Bill’s Pomodoro, and so Bill defers till after, but when he does, Joe’s in the middle of his Pomodoro and defers as well, and so on. Eventually someone’s Pomodoro has got to budge.

Introducing Power Hour

What’s needed is a shared Pomodoro, whereby the team understands when the clock starts and stops, and collectively agrees not to interrupt each other during that time. This is exactly what my we’ve created on my current project, and we call it “Power Hour” (not to be confused with any bevarage-oriented games you may or may not have played in college).

So far it’s been simple and effective. Each day we have two Power Hours, one at 10am and one at 2pm. During those two hours we all go “heads-down”, and get work done. If one of us has a question for another during that time, we wait till after Power Hour to ask it. There are obvious exceptions (bugs in production, calls from directors, free food in the cafeteria, etc.), but for the most part the sanctity of the hour is respected (even, now, by others outside of the team).

It may seem that this technique might thwart communication, but in practice it just consolidates it, often to the 15 minutes before and after a Power Hour. If I need an answer to a question before I start my work, I know I’ll need to ask my colleague before Power Hour begins, and vice-versa. This is healthy trade – rather than a work-day full of randomly distributed interruptions, discussions organically converge into concise bursts.

Who knows if we’ll have the discipline to keep up our Power Hours, but for now they’ve been a big help in countering the pressures for multitasking. I’d be interested to hear your strategies for getting quality work done, efficiently. Please share!

©2012 Summa Blog. All Rights Reserved.

The speakers included leaders from three of our customers, each talking about their personal experiences introducing Agile into their organizations, the benefits that they have realized, and the challenges that they overcame.

Tom Vrana, Assistant Director of Enrollment System, discussed how Carnegie Mellon University is using Agile to reduce risk and engage business users to revamp their proprietary enterprise student information system.

Gerry Perham, CTO of SmartOps, shared how his organization rapidly adopted Agile, leading to a significant upgrade in technical competitiveness in only 6 months.

Michael Meissner, VP of Software and R&D at Omnyx, stressed the importance of culture and getting the organization comfortable with being uncomfortable in order to reap the benefits of ‘unconstrained Agile.’

The keynote address was given by Andre Dhondt with Rally Software. Andre’s talk focused on the importance of establishing a culture of team work and cooperation to the successful implementation of Agile.

An interactive question and answer session with all four of the speakers followed the individual presentations. This provided an opportunity for the attendees to relate the benefits and challenges that they have in their organizations, and to ask for advice on addressing them from the panelists. Questions included topics such as how to make Agile work in a distributed environment, how to scale Agile across large organizations, and how it can help users prioritize feature requests.

It was great to see so many enthusiastic attendees coming out to learn how Agile best practices can help improve their organizations.

Special thanks to Tom Vrana, Gerry Perham, and Michael Meissner in making this event possible and sharing their stories.

Agile can provide many benefits, but it is not always easy to get started.  One of the themes that each of our customer speakers touched on was the importance of having the right partner to help make the transition to Agile successful and the right tools to help facilitate communication within their teams. Are you starting your Agile journey and looking for advice or support? Have you already started to use Agile and are looking to take you teams to the next level? Summa can provide experienced Agile coaches, as well as skilled architects and technical consultants with experience working with Agile teams.  Contact us to find out more.

Q&A Panel with (from left to right) Andre Dhondt, Tom Vrana, Gerry Perham, and Michael Meissner

©2012 Summa Blog. All Rights Reserved.

It’s actually been quite a few years now that the term “social” has taken on a new significance in our lexicon. It still means what it’s always meant, of course: “pertaining to…relations…community…companionship”. And the underpinning of the social communal relationship has always been sharing – sharing feelings, ideas and thoughts.

The growth of social media outlets has fostered this sharing like never before. The most widely-recognized social platforms (Facebook, Twitter, YouTube, LinkedIn) have enabled personal, individual connections and sharing by bringing strangers together and reconnecting lost relationships. Seeing an opportunity to leverage these social networks, businesses also can now reach discreet segments of their customers, receive immediate feedback and target promotions like never before.

But what about within the organization? Should companies be considering ways to use social platforms to increase collaboration, efficiencies – and revenues?

There is, in fact, a role for social collaboration throughout the enterprise. And there is a solution – Salesforce.com’s Chatter.

Collaboration’s obstacles

As efficient as we’ve become, collaboration in the workplace is generally much harder today:

• Organizations are larger, with unique structures and roles
• Organizations are more disperse, with multi-site locations
• The virtual workspace has moved employees away from each other
• Business is faster-paced
• We are all exposed to content overload, and sifting through it all takes time
• …and then there’s NOISE…the irrelevant, insignificant and unneeded information

What is Chatter?

Chatter is Salesforce’s cloud-based enterprise social network. Chatter fosters collaboration within your organization by:

• Enabling relevance – your staff chooses the information that’s important to them, bringing the conversation to the subject
• No more seeking for important information – Chatter pushes relevant updates directly to users
• Delivering efficiency – through automated feeds, your employees have quick and seamless access to relevant content
• Shrinking the organization – bringing remote locations together
• Cutting through the noise

Chatter’s value

In a study done by Nucleus Research in July 2011, Chatter has proven to directly contribute to an organization’s productivity and efficiency:

• Companies adopting Chatter to support business collaboration drove greater productivity – but also made employees more aware and aligned with company goals
• Chatter users experienced a 12.5% increase in productivity (on average)
• Productivity savings were often seen to have a direct impact on the improved performance of the sales team
• With increased manager visibility through automated feeds, managers are more quickly aware of events, setbacks or actions needed
• Improved responsiveness was seen with topic/customer-specific questions, delivering solutions that are more on target with reduced cycle-time

Features of Chatter

Taking some of the best features of the most popular social platforms, Chatter brings your workforce together, and improves the visibility and dialog throughout the enterprise. Some of Chatter’s key features include:

To learn more about Chatter and the Social Enterprise, contact Orion Wolff at orionw@summa-tech.com.

Next week: a deeper dive on some of Chatter’s most impactful features.

©2012 Summa Blog. All Rights Reserved.

I grepped the logs, and the first result looked something like this:

123.123.123.123 - - [27/Feb/2012:01:40:24 -0500] "GET /reporting/some_report?param1=somevalue&param2=something HTTP/1.1" 302 - "https://mail.google.com/mail/?ui=2&view=bsp&ver=ohhl4rw8mbn4" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; TencentTraveler ; .NET CLR 2.0.50727; .NET CLR 1.1.4322; msn OptimizedIE8;ZHCN)"

The request was for a sensitive report. You can see in the same line that this request resulted in a redirect (302). Subsequent log entries showed that the redirect was for the login page. This is expected behavior for a user that is not currently logged in and attempts to deep link into the application.

The unusual thing about this request was the referrer; gmail. The other accesses with the same User Agent showed a similar pattern. All had tried to access the same report and were then re-directed to the login page. All of the original referrers were an obvious web mail client.

It was clear that this was a CSRF attack. The user had opened up a malicious email using their web mail client. The attacker who had sent the email then issues a request for the sensitive report, hoping that the user is currently logged into the application. How the attacker harvests this information is unclear.

I wanted to see how many CSRF requests were in the logs. I could have just grepped for the report string that I saw in the Tencent Traveller entry but
that would have also shown me all of the legitimate accesses. I also wanted to see if different reports/pages were trying to be accessed as well.

Time for a a perl script:

This perl script will process multiple log files looking for accesses where the referrer is not from the expected domain and the request is not the login page or the root context (/). The most complicated thing about this script is the regular expression that is used for parsing each line of the access log. $log_pattern uses the newer perl feature of named captures to capture the fields that I’m interested in $+{referrer}.

Running the script showed many more accesses for the same sensitive report all with referrers that were obvious mail clients. My next question was if any of these CSRF attacks were successful. I confirmed that submitting a request for /reporting/some_report in the test environment resulted in a response with a 200 return code. All I needed to do was to see if any of the CSRF requests in the logs also had a 200 return code instead of a redirect return code of 302.

I modified the regular expression to also capture the return code:

and an additional check on the return code:

Running the script again revealed no successful attacks. The attacker was probably mass mailing untargeted SPAM in the hopes that he would be lucky enough to find not only a logged in user but also some one who even used the application. I would be surprised if this site was the only site that was being targeted by each email.

A quick way to guard against most CSRF attacks is to examine the referrer on accesses to sensitive URLS. But this is not a magic bullet. The referrer field can be spoofed in a sophisticated attack. The correct solution is to generate a unique token per session and have each user request submit that token as either a query string or a post parameter.

©2012 Summa Blog. All Rights Reserved.

It’s also telling me I could Golf for 1 hour and 15 minutes to still hit my goal. That sounds like more fun.

Last summer and fall, Summa worked with BodyMedia, Inc. to design and implement the new FITCoach feature. We did it using decision management technology from IBM.

This week, Brett Stineman of IBM is hosting a virtual panel with Steve Menke, CIO of BodyMedia, and myself, to talk about the project. The panel is at 1PM ET on Wednesday, March 28. You can register for the virtual panel here.

BodyMedia is also going to be featured as a main tent session at IBM’s Impact conference in Las Vegas next month. Christine Robbins, CEO of BodyMedia will be presenting at the main tent. Via Tsuji, our resident BRMS expert and regular blogger, will also be co-presenting at a technical session with Steve Menke, CIO of BodyMedia.

We’d love to see you at the Virtual Panel this Wednesday, or at Impact in Las Vegas in April!

©2012 Summa Blog. All Rights Reserved.

BRMS requires a paradigm shift in most organizations. Before embarking on a BRMS implementation, know that the enterprise is ready and prepare it for the changes that a BRMS would need to be truly successful:

• Reliance on Stakeholders. Stakeholders from both IT and the line of business must understand that in order to fully define, build, deploy and maintain rule-based applications, both parties must be fully committed to the task. Resistance from the business users to author rules (i.e. “I don’t want to be a programmer”) must be managed. And IT must resist the urge to implement the changeable logic for business users (i.e. “It’s easier and faster if I do it in code”). Both parties must share the same vision– the heavy lifting upfront is done to make the work easier and faster in the future.
• Management Endorsement. Support from management is critical to the success of a BRMS implementation. BRMS requires a comprehensive set of management capabilities to handle the specific needs of the LOB and IT (Stineman, 2009). Managers have to understand and support the changes in roles and responsibilities that will occur as a result. Expectations from the LOB and IT must be mutually agreed upon and overseen. As such, job descriptions, performance goals, and support structures would need to change as well. For example, business users are more involved with rule authoring and troubleshooting, while IT would need to coordinate with business users more, knowing when deployments are made.
• Enterprise Wide. Oftentimes, BRMS is considered for a specific application. The return on investment (ROI) may not always be worth the implementation. Consider sharing the BRMS to the entire enterprise – not only does the ROI increases, but stakeholder support as well.

As important as it is for the business users and IT to plan the BRMS implementation together, it is even more important that they execute it together.

In normal software implementations, business users participate in the elaboration phase for requirements specification, become minimally involved during IT development, and return for quality assurance. But in BRMS, building the “business user interface” is important (Sparkling Logic, 2010). Design the BRMS around the business. Balance the focus of the implementation between the technical and the business aspects.

When approaching the implementation from the business’ point-of-view, IT is forced to design the BRMS interface such that it makes sense to the business. Doing so will allow the business users to be more efficient and effective when writing the rules and increase the quality of the underlying artifacts. Likewise, IT will also gain efficiencies by not having to field questions or troubleshoot problems that they could have avoided if they would have designed the system around the business users.

The key aspects to focus on when designing the user interface are the following:

• Representation of Business Concepts. Depending on the BRMS product selected, this task could be easier on some and more difficult in others, but the intent is the same – design the business object model and/or the vocabulary used to author rules close to the “business user speak”. The underlying data models could be complex and difficult to navigate, but if the object model (perhaps accompanied by a well-mapped vocabulary) designed to write the rules is easy to understand, the business users will find it easier to write the rules.
• Packaging and Grouping. Packaging (e.g. rule sets) is natural for an IT practitioner, but is often a foreign concept to a business user. Name rule folders, packages and sets with simple, business-friendly names. Avoiding cryptic naming conventions involving numbers and IT codes. Structure the packages such that the business user need not traverse multiple locations for maintaining related rules. Within the rule sets, design a folder hierarchy that makes sense to the business user – often, it is effective to associate the names of the folders closely with the rule flow.
• Navigation and Metadata. Often, business rules are related to other rule artifacts. As more rules are developed, business users require more dynamic navigation. Depending on the BRMS product, built-in features may already be available to support these types of activities. Work with the business users when designing these components. Keep in mind how they can also be employed for the technical design and implementation.
  • Tagging. If the product supports tagging (e.g. categorization), choose categories that make sense to the business users.
  • Rule Metadata. If the product supports adding custom metadata to rule artifacts, consider how the business users might need additional attributes to describe the rule artifacts for their documentation and search.
  • Custom Views. If the product supports custom views and queries for presenting rules, design them to support business users’ day-to-day activities.

Though the business user interface is important, this does not imply that the technical implementation is less valuable to the success of an implementation. They are equally critical to the whole system. In fact, it is important that developers are responsible for the structure of the rule projects and the pilot development of the rules. Though rules can be written by business users, the initial structure must be designed to ensure good performance and consistency. This cannot be done by business users alone.

Thus, IT must guide the business users with the following:

• Naming conventions. Business users should be able to name rule artifacts in a user-friendly manner, but conventions are still important and is not a concept that business users are generally accustomed with. Establish conventions for consistency across different business user groups. This helps both business and technical users when working in different rule spaces.
• Templates. If the BRMS product allows, make use of their template features. Otherwise, share rule templates with business users, when they start to author new rules after the initial implementation.
• Rule Authoring Guides. IT can provide rule authoring guides to business users, outlining the best practices for authoring and/or updating rules. This can help with quality maintenance, e.g. suggest rule patterns for good performance, warn against rule patterns that can cause infinite loops, encourage running rule analysis (if the BRMS product supports this feature), and establish guidelines for testing and validation.

Management, the line of business and IT must all be ready and prepared for the BRMS implementation. Agree on roles and responsibilities and commit to necessary organization changes. Balance the implementation between the business users and IT. Increase the communication and coordination of the two groups to ensure success. With the entire organization on board and the system designed and configured to support the business, you can reap the benefits of a successful BRMS implementation, that is not only reflected in your bottom line but by your stakeholders as well!

References

Dixon, J., & Jones, T. (2011, July 25) Hype Cycle for Business Process Management, 2011.

Gartner. (n.d.). Gartner Hype Cycle. Retrieved February 21, 2011, from Gartner: http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

Sparkling Logic. (2010, February 16). #1 Pitfall in Decision Management. Retrieved February 18, 2011, from Everything Decision Management, Technically Speaking: http://techondec.wordpress.com/2010/02/16/1-pitfall-in-decision-management/

Stineman, B. (2009, November). IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and Developers. Retrieved February 18, 2011, from IBM: ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/wsw14091usen/WSW14091USEN.PDF

©2012 Summa Blog. All Rights Reserved.

What do we learn from the books?

The most obvious and maybe intuitive way to generate random numbers in Java is simply calling:

java.lang.Math.random()

Random generation is in the Math utility class with abs, pow, floor, sqrt and other mathematical functions we see in all other languages. Most people will learn about this class in books, tutorials and classes. The utilization is simple: a double is returned between 0.0 and 1.0. With this basic information, a developer usually writes something like:

Math.random() * 10

…to generate a double between 0.0 and 10.0, and:

Math.round(Math.random() * 10)

…to generate a integer between 0 and 10. Static imports can make these expressions shorter but casting can be annoying, especially if wrapper classes are involved.

One step further

By reading the source code of Math.random() or simply playing with the IDE’s auto-completion feature, a developer can easily notice that java.lang.Math.random() uses an internal random generator object – a powerful object with the flexibility to generate randoms of booleans, all numeric types (with and without range) and even Gaussian distributed doubles. For example:

new java.util.Random().nextInt(10)

This amazing object does have one drawback, however: it is an object. Its methods are only accessible through an instance, which means the constructor must be called. Expressions like the one above are acceptable if memory is not an issue, but it feels that something is not right.

A simple solution to avoid creating a new instance of Random each time you need a random number is to have a singleton instance using a static class, but by doing this you will be essentially replicating what java.lang.Math does. Maybe a safe way is to copy the lazy initialization and have your improved version of java.lang.Math. This works, has low maintenance, but you may want some simple unit testing just to make sure it is working.

The storage problem comes from the assumption that the code which calls it only wants a random value. Sometimes there is a need to manipulate or protect the seed, an internal number used to store the state and calculate the next random number. In these special cases a public accessible random generator is not appropriate.

Concurrency

In a multi-threaded environment like a Java EE application, the random generator object instance can still be stored as a static attribute in a class or some other implementation of the singleton pattern. Fortunately, java.util.Random is thread-safe so there is no risk to corrupt the seed with calls from multiple threads.

Another option worth considering in a multi-threaded scenario is a java.lang.ThreadLocal instance. The idea of a lazy initialized singleton is implemented by a native Java API and you also have a guarantee of one instance object per thread. No more trouble with concurrency and no more trouble with unit testing.

One thing is still not right: Java did not provide a good way to manage the singleton java.util.Random instance and through this post it was discussed ways to build that. Well, the long awaited Java 7 provides a new way to generate random values:

java.util.concurrent.ThreadLocalRandom.current().nextInt(10)

This new API mixes the advantages of the two other approaches: singleton/static access like Math.random() and flexibility. ThreadLocalRandom is also faster than any other approach in high concurrence scenarios.

EDIT

Fellow summanoid Chris Marasti-Georg pointed that

Math.round(Math.random() * 10)

causes an unbalanced distribution, e.g.: 0.0 – 0.499999 will round to 0 while 0.5 to 1.499999 will round to 1. The correct way to achieve a balanced distribution with the old style syntax is

Math.floor(Math.random() * 11)

Fortunately we don’t have to worry if we are java.util.Random or java.util.concurrent.ThreadLocalRandom.
Effective Java item 47 describes some the dangers of not using the java.util.Random API in the correct way. The lesson is do not use

Math.abs(rnd.nextInt())%n

instead use the API as designed: rnd.nextInt(n).

©2012 Summa Blog. All Rights Reserved.

See today, this day, it was up to us to present our interpretation of a poem by Robert Frost, the well known ‘The Road Not Taken‘. I agonized over the twenty lines of iambic tetrameter in front of me at the last minute, hoping, praying, that something, ANYTHING would jump off the page at me and give me a topic to discuss. Why would the traveler not come back? Is he dying? Why is he sighing? Is he sad about the yellow wood? My mind was racing.

All I could remember thinking was, ‘why on earth do I have to bother with this cryptic stuff?’ I was fresh from the Cliff’s Notes of Walden when now I had another piece of dusty old prose to analyze. ‘How would this ever benefit me in the future? When am I ever going to need this??‘

Well, it took seventeen years and one head of formerly-luxuriant hair, but I finally have a practical application for Frost’s poem. And yes, while it may be a stretch, if you have a better explanation for how I spent my formative years reading hundred-year old literature, then I’m all ears.

Recently, a colleague and I were discussing version control. He had been using Git on a current project and I was using Mercurial. He then asked me a pointed question for which I now regrettably realize I didn’t have a sufficient answer. He asked me, ‘what sort of daily workflow do you follow?’ I asked, ‘what do you mean, like commit, push, pull, etc.?’ and he replied, ‘yes’, basically asking how I maximize my efficiency in a distributed version control environment.

When I explained my rather pedestrian daily routine, he sent me a link to a post explaining an effective way to do it in Git. After reading, I felt like the same teenage dope that stood in front of the class and explained that the yellow wood in Frost’s poem meant rebirth (it doesn’t). I essentially had no real explanation at all. I simply wasn’t prepared.

So, this is my attempt at constructing a daily workflow, Mercurial-style, while simultaneously making use of my years in English class. Now if anyone can provide a reason why I read the Red Badge of Courage, I’m all ears.

Two branches diverged in a local repo
And sorry I had to push from both
And be one developer, long I stood
And looked through the history as far as I could
To where they were cloned in the undergrowth

The first thing I noticed in the blog post about Git was that its purpose was a rebase workflow. It favored the approach of branching to contain and isolate all your incremental changes and commits locally. Then when they were ready for primetime, they were rebased to the main branch and inflicted on an unsuspecting populace. The only problem was that using branches for this sort of thing would not work in Mercurial. At least not effectively.

Branches in Mercurial represent a parallel path of development within the same repository. For example, a branch, ‘Release1′ is creating from the default where all developers can apply bug fixes for Release1, while at the same time the default branch represents ‘Release2′ and continues on with its new feature sets. These branches can be created on the central repository and then pulled down locally. If you are working on a Release1 fix, you simply update your working directory to Release1 locally. Working on a new Release2 feature? Update to default.

The problem lies in the realization that when it is time to push, ALL commits in BOTH branches will need to be pushed. Sure, there are extension-based ways around this with shelving and transplanting, but the out-of-the-box behavior is to send all commits on their way. This means that if your fixes for Release1 must go out the door now, then they’re taking everything with them, including all those work-in-progress Release2 features you’ve committed locally.

So, the Mercurial way is actually a combination of branching and cloning. My approach is to clone my repository into as many child repos as is needed, say one for every active branch in the central repo. This way, you can push from a repo of your choosing, while still holding back any changesets you committed but aren’t ready to unleash. So, taking our scenario above, the setup would look something like this:

Granted, because the clones are uhh, clones of the main local repo, which is in turn a clone of the central repo, they will contain both branches. However, all you need to do is make sure each is always updated to their appropriate branch and you never need worry about which branch you’re in when making a change. Trust me, this is not always easy and has burned me quite a few times.

Then took the other, as just as fair,
And having perhaps the new feature
Because it was buggy and wanted flair
Though as for that the coding there
Had diverged it into its own new creature

So, now you have two repo clones that are based off of your main local repository, which in turn, is based off the central repo. The newly cloned repo is even smart enough to know from whence it came, so now you are free to make changes to this cloned repo, commit at will, and then when ready, the feature or the bug fix can be pushed to the main local repo.

Before you do however, you will want to pull from the central repo to your local and then in turn, pull into your cloned repo. This way, all merging that needs done will be performed on the cloned repo, leaving your main repo as the staging area for shoves back into the central one.

Mercurial’s approach of requiring merge commits can leave the repository cluttered with numerous commits with the message, ‘Merge’ with no real content. In addition, each developer’s local commits will also be pushed, so every ‘Ugh, still broken’, ‘Bug fix’, and ‘DO NOT navigate to this page yet’ commits will be bared to all. However, there is an answer to this, but its not an easy one to accomplish. Each of these nonsensical merges and interim commits can be combined into one changeset. You can perform this concatenation in the clone repos and then push a single, solitary, meaningful changeset (or several as long as they’re meaningful) to the main repos. Take a look at this link for further reading on ConcatenatingChangesets.

And both that morning equally lay
In revisions no commit had trodden black
Oh, I kept the default for another day!
Yet knowing how testing leads to dismay,
I doubted if I should ever update back

Once this setup is up and running, you’ll find that very little need be done on your central local repository. The idea of having to clone an entire repository, especially one per branch as we did above seems like overkill, but it does provide a clear and definitive way to keep your lines of work distinct and separate while at the same time giving you great flexibility in managing your code.

Now, for a practical example. To start off, notice my prompt in the terminal. Through the use of a very nice Mercurial plugin called Hg Prompt, I am able to print repository information in my prompt so that I am always aware of 1) what repo I’m in 2) what branch of the repo I am in and 3) what I have incoming and outgoing. This simple plugin makes working in a multi-repo and multi-branch environment extremely easy.

1. Notice the main repo (frost) has two branches, one for release1 and one for default, which represents the current line of development. What I’ve done here is clone my main local repo twice, one for each branch. So I now have a local repo cloned from the central (frost) and two additional ones cloned from that.

2. Next, I update the frost-release1 repository to the release1 branch and leave it there. This way I don’t have to worry about mucking around with changing branches. I then do the same to release2. Each repo is now dedicated to a branch.

3. Now, we are actually making changes to the repos. Notice that I’ve added a new file to the release2 repo. The ‘?’ in my prompt tells me I have an untracked file and the ‘!’ tells me I have changes to commit. All thanks to our hg-prompt extension.

4. Next, we change back to our main local repo. Here, I have configured two additional paths so that I can determine incoming changes to my main local repo from my clones. Notice the additional parameter to ‘hg in’, which allows me to specify a repo to find incoming changes. The paths are denoted in your repository-specific hgrc file as follows:

5. Now, I am able to see that I have one incoming changeset from one of my local clones.

6. Say that I need to get release 1 changes pushed quickly for a patch tonight. In regular One Repo Land, I would have to push all committed changesets in my local repo. But, here, we can simply pull from the repo we need and push the changes up. Running an ‘hg out’ on my main local repo will show that my only outgoing changes are for my release1 fixes. My release2 features are still safe and sound in their own repository. A simple push and the fix is in.

A few notes:

1. I understand it may seem a bit heavy-handed to make three clones for local work, but cloning in Mercurial is not only easy and cheap, but encouraged. Mercurial uses hard-linking on the file system to only track differences, not entire files throughout their history.

2. The reason I chose one main local repo and two clones instead of just two clones of the central repo is that this gives me a staging area for ready-to-push changes while also allowing me to pull and run the most current code MINUS my changes.

3. Again, I understand it is possible to avoid pushing all commits from every local branch, but this involves some maneuvering of changesets using extensions. I am trying to give a simple approach that will avoid that process.

So, that is my humble attempt at creating a practical rebase workflow in Mercurial while pretentiously incorporating turn-of-the-century lore. I always knew there was a reason I was sweating over those wordy old poems and tomes.

I shall be telling this with a sigh
Somewhere projects and projects hence:
Two repos diverged in a local wood, and I–
I took the one less developed by
And that has made all the difference

©2012 Summa Blog. All Rights Reserved.

Global Scope

var globalVar = "This is a global variable";
globalNotExpliciltyDefined = "global variable not explicitly defined";

function ScopeObject(arg1){
    this.publicVariable = "public variable";
    this.paramMadePublic = arg1;
}

ScopeObject.prototype.publicMethod = function(){
    return "public method executed";
};

var myScopeObject = new ScopeObject("constructor param");

myScopeObject.publicVariable;     //returns "public variable"
myScopeObject.publicMethod();     //returns "public method executed"

function ScopeObject(arg1){
     // arg1, when directly accessed in the constructor, is in private scope

     // ...existing public scope code omitted

    var privateVariable = "private variable";

    function privateMethod(){
        return "private method executed";
    }
}

var myScopeObject = new ScopeObject("constructor param");

myScopeObject.privateVariable        //returns undefined
myScopeObject.privateMethod()      //produces TypeError: Object # has no method 'privateMethod'

ScopeObject.prototype.publicMethodCallsPrivateMethod = function(){

    // call the private method defined in the constructor
    privateMethod();

    return "public method calls private method executed";
};

function ScopeObject(arg1){
  // ...existing public scope code omitted
  // ...existing private scope code omitted

  this.privilegedMethod = function(){
      return "privileged method executed";
  }
}

this.privilegedMethodCallsPrivate = function(){

      console.log("in privileged method, privateVariable is : " + privateVariable);
      privateMethod();

      return "privileged method calls private executed";
  }

function ScopeObject(arg1){
    this.publicVariable = "public variable";
    this.paramMadePublic = arg1;

    var privateVariable = "private variable";

    globalNotExpliciltyDefined = "global variable not explicitly defined";

    function privateMethod(){
        console.log("private method : executing...");
        return "private method executed";
    }

    this.privilegedMethod = function(){
        console.log("privileged method : executing...");
        return "privileged method executed";
    };

     this.privilegedMethodCallsPrivate = function(){
          console.log("privileged method calls private : executing...");

          console.log("in privileged method, privateVariable is : " + privateVariable);
          privateMethod();

          return "privileged method calls private executed";
     };

}

ScopeObject.prototype.publicMethod = function(){
    console.log("public method : executing...");
    return "public method executed";
};

ScopeObject.prototype.publicMethodCallsPrivateMthod = function(){
     console.log("public method calls private method : executing");
     privateMethod();
     return "public method calls private method executed";
};

©2012 Summa Blog. All Rights Reserved.

Meet and network with HIT professionals from Pennsylvania and the Delaware Valley region, and learn about your local HIMSS chapters, all while enjoying food and drinks conveniently located at the Venetian. All WPHIMSS, CPAHIMSS, and DVHIMSS members and their guests are welcome to attend.

Tuesday, February 21
7 p.m. to 9 p.m.
Lagasse’s Stadium – In the Venetian
3355 Las Vegas Blvd., South
Las Vegas, NV 89109
(In the “Endzone”)

Please RSVP to wphimss12@summa-tech.com to let us know who will be attending or for more information on the event.

©2012 Summa Blog. All Rights Reserved.

Enterprises could highly benefit from a BRMS if it is characterized by the following conditions (IBM):

• Frequent Business Rule Changes. Rule changes originate from evolving business conditions (e.g. competitive pricing), regulatory amendments (e.g. government compliance laws), and varying organizational practices and policies (e.g. validation and feasibility checks). Organizations with frequent business rule changes are fortunate if modifications to their business policies and/or rules are foreseen and scheduled. However, in reality, this rarely happens. Oftentimes, the necessary changes are not implemented in the required IT systems correctly and/or on-time, risking missed opportunities or regulatory violations. Enabling the LOB to change the rules themselves through a BRMS shortens the release cycle for these changes and helps decrease the risks.
• Highly Variable Decision-Making. Certain business models require customized and/or personalized decisions, specific to locality, product, process or the customer itself (e.g. verification and pricing rules). When embedded in an application, the decision logic for these requirements is complex and even more complex to change and validate. With a BRMS, the organization is equipped with flexible and standard mechanisms for expressing and validating these complex rules.
• Enterprise Logic Sharing. Without a BRMS, business logic that is shared in different applications throughout the organization is either duplicated or embedded in the database. This model works well, until the logic needs to be modified. Logic changes are cumbersome to propagate or are implemented inconsistently. The shared repository and versioning capabilities of a BRMS reduce or eliminate these challenges.

Another pitfall to properly recognizing the need for a business rule management system is confusing its need for other decision management technologies. Sometimes the business problem requires a BRMS in combination with other systems. Other times, the solution may not need to involve a BRMS at all.

Decision management is a “practice of combining software and expertise to automate and improve decision-making within critical business systems”. The core purpose is to “make the best possible decision at the current moment based on data and situational context” (Wilson & Stineman, 2010). Not all decision management scenarios are necessarily a call to action by a business rule management system.

The fundamental distinctions of a BRMS from other decision management technologies are determining the decision based on what is “known” (e.g. corporate policies, regulations) and providing the tools to manage and govern those decisions. A BRMS does the following well: (1) standardizing of operational decisions; (2) straight through processing; and (3) decision brokerage (FICO, 2006).

However, it does not perform well when the problem involves waiting for human intervention, making asynchronous calls to remote systems or gracefully handling errors and exceptions to other services (Sparkling Logic, 2010). In those instances, look to other decision management technologies:

Business rule management systems can undeniably benefit enterprises with real business problems associated with highly variable and complex decision logic. Validate the need of the tool in the enterprise before getting caught up in the “hype”. Know the needs of the organization and how a BRMS can fulfill the requirements. Explore other decision management technologies and ensure that a BRMS is the right system for the organization. And reap the benefits of a much needed BRMS implementation!

References

Dixon, J., & Jones, T. (2011, July 25) Hype Cycle for Business Process Management, 2011.

FICO. (2006, February 9). Are BPMS and BRMS complementary or not? Retrieved February 17, 2011, from FICO Decision Management Blog: http://www.edmblog.com/weblog/2006/02/are_bpms_and_br.html

Gartner. (n.d.). Gartner Hype Cycle. Retrieved February 21, 2011, from Gartner:http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

IBM. (n.d.). What is a BRMS? Retrieved February 17, 2011, from IBM: http://www-01.ibm.com/software/websphere/products/business-rule-management/whatis/

Sparkling Logic. (2010, February 16). #1 Pitfall in Decision Management. Retrieved February 18, 2011, from Everything Decision Management, Technically Speaking: http://techondec.wordpress.com/2010/02/16/1-pitfall-in-decision-management/

Sparkling Logic. (2010, August 24). Business Rules in or out of BPM? Retrieved February 17, 2011, from Everything Decision Management, Technically Speaking: http://techondec.wordpress.com/2010/08/24/business-rules-in-or-out-of-bpm/

Wilson, C., & Stineman, B. (2010, November). Clear up confusion over BRMS, BEP, BA & BPM. Retrieved February 17, 2011, from IBM: http://www-01.ibm.com/software/solutions/soa/newsletter/nov10/brms.html

©2012 Summa Blog. All Rights Reserved.

As the release approaches we’ve hit thebutton on five of the top features. This list is written from a user and administrator perspective for people who both use and configure Salesforce systems on a daily basis. Be sure to add the features you’re looking forward to most in the comments section. Enjoy and happy Spring ’12!

5. Chatter Messenger

If your organization uses a chat client such as gchat, yahoo messenger, msn messenger, etc… for interoffice communication this feature will be of great interest to you. Chatter users will now be able to have live chats with each other using Chatter Messenger from within the Salesforce application. This could be used as another way to make Salesforce the go to application for your users, driving faster adoption across the organization. This feature will also be available to Chatter Plus and Chatter Free users, so truly anyone at your organization would be able to use this feature. It will be interesting to check this out with customer groups to see if chatting with customer Chatter users is also an option.

As you can see in the screenshot below, the interface is very similar to a popular social network we all love and/or hate:

A few things to consider when implementing this feature:

• For Spring ’12 this is being released as a Pilot Program, so you may need to contact Salesforce to have Chatter Messenger turned on
• Chatter must be enabled for Chatter Messenger to be enabled
• A user must follow another user to chat with them
• Chatter Messenger can be disabled without disabling Chatter

4. Case Feed

In Service Cloud engagements in the past we’ve been asked to customize the Case entry, update and detail screens to maximize screen real estate and have had to replace these screens entirely with custom VisualForce screens that use APEX do AJAX updates. A number of those customizations will now be taken care of using the Case Feed feature in Spring ’12.

This feature gives agents the ability to create, review and update Cases from a screen that gives them relevant Case details, Chatter feeds and also allows responses through multiple channels without navigating to another screen. The sidebar on this screen lets agents quickly switch between activities such as logging calls, Case notes, Case details as well as responding directly to the customer.

To use this feature Chatter must be enabled as well as Chatter tracking on Cases. For high-volume call centers that best utilize Chatter, this feature will be high impact and much easier to use and maintain than custom VisualForce solutions of the past.

3. Analytics Edition

Analytics Edition brings the advanced, BI-like reporting so many have wanted from Salesforce for so long. This is an “Edition” feature which means you will need to add this edition to your org for an additional fee (available for Professional, Enterprise and Unlimited Editions). Contact your Salesforce rep for pricing The major new types of reports are:

• Joined Reports: Create and run reports pulling data from multiple objects. (EX: Report on an Account’s Opportunities and Products associated with those Opportunities)
• Cross filters: Filter across multiple objects. ( EX:  Filter to see Cases from Organizations in a certain Region that also have Opportunities open that are greater than $100k)
• Bucketing: Segment your data on the fly without changing your data model. ( EX: report on open Opportunities by deal size, and group them into custom “Large”, “Medium” and “Small” groupings you create within the report.)

2. Console Push Notifications

A major concern our customers have raised is the issue of two agents or sales reps updating the same record simultaneously. This creates what in the programming world is called a “race condition” where the users are unknowingly in a race to get to the Save button last so that their changes are the changes ultimately saved on the record. This is especially a problem for high-volume call centers, both on Sales and Service Cloud. Now users will be able to see real-time push notification of field and record updates in the Salesforce Consoles.

As a user is viewing a queue or list view, or even updating a record on its detail screen, they will see changes being made by other users in real-time. Administrators can configure colors and bold text to be used to alert users of ongoing changes to a record, and the live notifications can be activated for the following objects (all fields):

• Custom Objects
• Cases
• Accounts
• Contacts
• Leads
• Campaigns
• Opportunities

1. Schema Builder

From an administrator or developer point of view, this is almost undoubtedly the most anticipated feature of Spring ’12. Schema Builder has been available in a limited beta version that allowed users to read-only views of their org’s schema since Winter ’12.

Schema Builder in Spring ’12 (still in beta release, available in All Editions) can now be used to create custom objects, fields and relationships in an extremely fast manner. Custom objects can be created by dragging and dropping, fields and relationships created without the tedious clicking from screen to screen ways of the past. This feature should speed up creation of these objects, fields and relationships by an order of magnitude over the old way admins were forced to click from screen to screen.

Another advantage is the views of your database schema available to you to use for documentation, testing out new schema changes in the sandbox and to see the true data relationships that underlie your Salesforce instance.

The Schema Builder feature is probably best described through a demo, so I’ve included the following Spring ’12 release preview below. Hit the 4:20 mark to go right to the Schema Builder demo.

©2012 Summa Blog. All Rights Reserved.

The framework as-packaged includes facilities to help with many common aspects of contemporary application development, from a Model-View-Controller (MVC) framework to  integration with persistence managers and elegant transaction management. But it doesn’t necessarily cover every need. One example of a gap is batch processing.

The idea behind batch processing is to allow a program to run without the need for human intervention – this may involve solving a problem that takes a lengthy amount of time, processing a large input set, or just automating some business process that doesn’t necessarily need to be triggered by a human. The batch paradigm was far more dominant in years past than it is in contemporary business computing, but that doesn’t mean valid batch use cases don’t continue to crop up. The operating system you’re using right now likely uses a batch approach to do all sorts of things for you without bugging you about it. Enjoying those automatic backups?

So what if you’ve got a problem that calls for a batch style solution but you’d still like to use Spring? On a recent project, we realized that much of the business logic we’d just finished writing within a web service framed with Spring could be reused for an upcoming batch component (which involved processing a potentially very large XML document that would be uploaded by a business partner). We briefly considered rolling a separate application that reused some of the same code, but before we went down that road someone mentioned hearing of “Spring Batch” – something that was not a part of Spring proper, but an auxiliary framework meant to complement it.

As you can read on its home page,

Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary.

Sounds great! So I dove in and started learning more about it. As I read the documentation, however, I have to admit I got a little overwhelmed by the complexity and amount of configuration needed for even a simple example. Unlike your average Spring application context, the context of a Spring Batch application grows pretty quick and involves configuring a lot of stuff that, at the outset, it just doesn’t seem like you should need to configure. A “job repository” to track the status and history of job executions, which itself requires a data source – just to get started? Wow, that’s a bit heavy handed. Worried that I might be misunderstanding what I’d found, I did some searching and found that I wasn’t alone in thinking the API left something to be desired.

But I’m not going to get as down on Spring Batch as the author of the article I just linked to. The reason being – once I determined what we had to configure in order to get a functional batch job running, I discussed the components involved with my team members and our client and we realized we would appreciate having all of those things. Logged history of batch runs in a database would be good, especially if there were ever a problem or failure. Then our client asked – will we have a UI to control it if we need to?

Enter Spring Batch Admin. It’s unfortunate that the Admin capability is distributed separately from Spring Batch itself – because unless you hear about it or search with the right query, you might wind up rolling your own administrative UI unnecessarily. Of course you can write your own if you’d like – especially if you need to fit in with some pre-existing administrative app you may already have in place – but chances are you have better things to do and batch processing is just one portion of your project.

I’ve got a very important time-saving tip if you think you’d like to use the Admin UI, though: decide if you need it first before starting to develop your batch capability. I made the mistake of thinking it would be easier to get our batch capability working headlessly first, then bolt the Admin app onto the project, in an attempt to reduce complexity and break things down. Instead I wound up having to redo some of the POJOs and configuration involved in kicking off jobs to make what I’d done compatible with the Admin framework. In fact, starting with the Admin framework, and getting it up and running with its ability to run abstract jobs first, then customizing the jobs to meet your needs, would be the path of least resistance.

Once I had everything together, though, what a sweet capability this added up to! Using Spring Batch plus Spring Batch Admin gave my team a relatively low-overhead solution that allowed us to easily hand batch testing duties over to our client – all they had to know how to do was access a web page and click a button. Plus, we’ve given them a framework and a concrete example that is now easily repeatable – given a few POJOs and some copy/paste/modify of the application context XML, they could easily add new batch job types in the future.

That’s it for now – check back for a follow-up article in which I’ll dive into some example configurations and cover specific problems I encountered in my batch app and how I overcame them.

©2012 Summa Blog. All Rights Reserved.

(click to expand)

Step 1: Plan for the Test

Preparation is the trickiest part of usability testing. If good users are not found, relevant tasks not defined, or environments not set-up, the results of the test will be specious at best, or non-existent at worst! It is crucial, therefore, to develop the right foundation for test:

Find the Users: For the typical B2C web site, representative users can be found at any street corner or coffee shop. For many enterprise projects, however, users are not so easily located or accessed. Because users of enterprise software may have specific domain knowledge, work in different departments, or reside in different geographic offices, procuring access to them or aligning schedules can be a significant challenge. If possible, it is important to surmount these obstacles – real users will give more accurate feedback, and will be generally more receptive of the system when it is eventually rolled out, becoming advocates of it rather than opponents to it.

When it is not possible to find real users, representative users (e.g. mapping to defined personas), or even non-representative users, can be substituted with some success; many usability issues can be uncovered by users with no domain experience, a fresh set of eyes the most salient requirement.

It is well documented that usability testing requires no more than 4-6 users per round. Usability issues are typically universal and so are found early – there are diminishing returns for testing with any more than 6 users (i.e. they all tell you about the same problems!).

Plan the Tasks: Not every feature of an application can or should be usability tested. As noted above, it is important, therefore, to identify for usability testing only those features which are prominent, complex, or have a high cost of user error. Once these features are identified, a script of user tasks can be created. Note that tasks should clear, concise, and worded in a way that is independent of the design of the application (e.g. not “click ‘add item to cart’ and click the ‘purchase’ button” but rather “buy a widget”). Lastly, it is important both to run through the script yourself, and also ask another team member to do the same, and ensure that the script takes no more than 15-30 minutes to execute (with the assumption that a user unfamiliar with the application could take 3x this long).

Write the Post-Test Questionnaire: Depending on the application it may be useful to learn about not only the user’s performance (i.e. can they use the system) but also their preference (i.e. do they like it). Surprisingly, it has been found that the two do not always correlate – users may have problems using the application but say the like it, or use it fine but say they hate it. For this reason, it is important to supplement the observational data (i.e. notes from watching the user) with data from a post-test questionnaire. Note that demographic, qualitative, and quantitative data are important – so ask both open-ended questions like “how did you feel about XYZ?” and “on a scale of 1-5, was the system usable?”. Lastly, the late usability expert Randy Pausch advocated always asking at least one question after a usability test: “what were the two worst things about the system?”, guaranteeing that the user will be forced to shed light on at least two tangible usability flaws (and not try to avoid hurting your feelings).

Set up the Environment, Data, and Access: Finally, a stable and perhaps isolated version of the system must be available for the test participants to use. In many cases this will be the normal QA environment, but depending on the frequency of builds or transiency of the data, this may or may not be adequate. If it is not, alternatives may be either to deploy the system on your local machine or to create a special, temporary environment specifically for usability testing. The feasibility of these options obviously depends on the complexity of the application and dependent sub-systems, serivces, or data stores – a simple single web-app to single database may be easy to configure and deploy, whereas a complex system that leverages LDAP, multiple databases, an ERP, and a handful of external web-services would not be.

Additionally, for some usability test scripts, it will be necessary to have each user test with a fresh, pre-configured, non-confidential set of data (for example, maybe a user is asked to find the user with an outstanding balance, and so such a user must exist). If this is the case, a set of SQL set-up and tear-down scripts may be necessary, or perhaps just a script for manually re-creating the data via the user interface. In any case, it is imperative to understand the data dependencies for the test up-front, to ensure that tests go smoothly, and users find issues related to usability and not bad data conditions.

Lastly, in many cases the test subject will log in as a pre-configured, sample user, however in some cases it will be helpful for the user to log in as himself and see “his” data during the test. In this case, it is important to ensure the user has appropriate access control for the QA environment – and it’s not until he tries to log in that you discover that he doesn’t have authorization.

Step 2: Perform the Test

If planning is done correctly, actually performing the usability test should be a snap – your job is simply to make the subject feel comfortable, stand back, and watch what they do! Here are a few things to keep in mind.

Introduce Yourself and the Test: When meeting the user, it’s important to set a very informal, relaxed, and open atmosphere early, so that the user feels comfortable sharing how they feel about the system. To that end, be sure to mention the following simple points:

• It is the system that is being tested, not them.
• The system has issues, but it’s difficult for developers to see them because we are too close to the problem. This is why their help is so important.
• Negative feedback is actually more helpful than positive. No feelings will be hurt if they are frustrated or don’t like something.
• Their help is greatly appreciated, and will contribute to a better product.
• If they get stuck you can jump in and help, but otherwise you’ll stay quiet and let them drive.

After introductions, give them the test script and have them briefly skim the tasks. Convey to them that although the tasks should only take 30-45 minutes, they should feel comfortable taking their time.

Observe, Ask Questions, but Don’t Help: Once the user has begun, it’s important to let them use the system as they wish, even if it means them navigating down false paths (the whole point is to see how they would use it if you weren’t there!). As they complete the tasks, encourage them to talk, and be sure to ask probing, but non-revealing, questions, like “I saw that you clicked the ‘filter’ button but were surprised with the result – what did you expect would happen there?”. If the user is hopelessly stuck, then it may be necessary to give them hints, but otherwise remain an observer.

Take Notes: As the user completes the tasks, take copious notes of their actions, comments, and frustrations – these notes will trigger your memory later and fuel the Usability Observations list that you assemble. Many would argue that it is necessary to also video record usability test sessions, however, the benefit is rarely worth the cost in my opionion (even though it is relatively cheap): project stakeholders seldom take the time to actually view a usability test video session, users may be apprehensive and less honest when being recorded, and the set-up and storage of the recordings can be frustrating and time-consuming.

Step 3: Analyze the Results

Once the tests have been completed, the data must be analyzed and then synthesized into a set of actionable recommendations. To do so, two artifacts can be created, an objective Usability Observations List and a subjective Usability Analysis & Recommendation document.

Create a Usability Observations list: Go back through your notes, and record discrete usability issues that users encountered in a simple spreadsheet. The list should be objectively and tactfully worded, stating, for example, that the user “did not know what the word ‘invoice’ meant” and not “‘invoices’ should be called ‘bills’”. Consensus should be noted for each item (e.g. “3 out 6 users”), and each should be classified either as a “usability bug” (which would later be entered in an issue tracking system to be implemented during the current sprint) or as a “feature request” (which would be added to the product backlog, to be prioritized for a future sprint).

Create a Usability Analysis & Recommendation document: Finally, it will be helpful for project stakeholders to receive a high-level analysis of the usability test, summing up overall impression of the site’s usability (using both quantitative and qualitative data as useful), the areas of the system that were most and least usable, and a set of recommendations for future action (e.g. new features to the backlog, additional rounds of usability testing, etc.). This document may captured in a Wiki, stored in document control (e.g. SharePoint), or just sent via email.

That’s it! Again, I’d like to hear your thoughts on usability testing on enterprise projects. Please share!

©2012 Summa Blog. All Rights Reserved.

Take Down Your Task Board

If you really believe in eliminating waste, and your team is not co-located, the scrum board in your war room is nothing but waste.  The original purpose was for information to be accessible to the team.  You should be able to look at it and know immediately what your comrades are up to.  If you are co-located, you’d have to ask someone to go update the board for you.  That slows both of you down, which isn’t so lean.  This leads me to my next point.

Invest in an online storyboard and make it your homepage

There are a lot of good ones out there.  I prefer Rally (shameless plug for our new partner).  It gives us all the basics — stories, defects, test cases, a burndown chart, as well as a lot of really helpful plugins.

I know what you’re thinking — this is starting to feel like the old project management style.  What’s to keep Rally from becoming the new rigid project plan?  Like any tool, it can be abused, but consider the benefits:

• One story board for everyone to see, even if they’re in your Maui office.
• Team views that show you what your teammates are working on, so you can offer to help if someone is falling behind
• Sprint burndown and velocities to help you plan for the future

And heck, if you’re only happy with a story board on the wall, you could adapt what these guys are doing.

Invest in collaboration software

So we’ve got iteration tracking covered; how do we collaborate?  We’ve all been there when the guy you need to look at your broken code is working from home or sits at the other office.  Checking in questionable code is never a good idea, and you may be using centralized source control so you can’t use the wonders of Git and Mercurial to let your buddy pull in your changes and show you where you you went wrong with your NHibernate cascade.

Every distributed team needs, at a minimum:

• Screen sharing software — Webex, Join.Me, Skype, take your pick.  You need to be able to share your screen so you can see what’s going on.  Encourage pair programming over the wire to get people comfortable with the tool and getting to know each other’s style.
• Chat software (no investment there) — It’s quick, easy, simple, and most of all, quiet.  Nothing disturbs the development room more than a noisy phone conversation.
• Reliable internet access — It seems obvious, make sure all your guys have a strong connection.  Nothing slows collaboration down more than a code review Webex that keeps flaking out.
• Phone conferencing lines available to anyone, at the ready.  There are even some free ones out there — my team has used FreeConferenceCall with a lot of success.

Stick to the Agile Basics

If your team sticks to the agile basics, they are 90% of the way there to a strong development experience, even if they aren’t co-located.  A few things to remember:

• The team owns the code — collaborate and work together to find the best solution.
• Communicate progress and blocks — no one benefits if you don’t ask for help when you’re stumped, when you don’t want to be pushy about a block, or when you hide progress for fear of being assigned more work.  Communicate more and you’ll do more.  Just don’t communicate so much that no one else gets anything done…  :)
• Eliminate waste and ask questions about process — if you think something doesn’t have much benefit, speak up.  Maybe you’re right, or maybe you’ll learn something in the process.  Many of you are familiar with Seth Godin’s TED talk on this subject.  If you aren’t, go watch it.  You’ll like it.

©2012 Summa Blog. All Rights Reserved.