Archive for October 2015

We often receive RFPs (Request for Proposals) that demand a firm committed five year product roadmap. Similarly we are often criticized for not having such a “golden” roadmap when other competing products have. Having now worked in an Agile world for some time now, these requests seem stranger and stranger.

The quibble here isn’t with having a plan, it’s with the inflexibility these requests imply. That a company needs to set its course for five years and then any change in that plan is somehow a failure to deliver. That as knowledge and circumstances change that you need to stick to the plan and not adapt to the new situation.

Products are now introduced in “Internet” time. This means they are updated far more frequently (sometimes several times a day). All companies are looking to be “disruptive” and to “redefine” their market. Under these fast moving and fast changing conditions does it make sense to have a fixed long term roadmap?

On the other hand a product needs direction. A product needs long term thinking. You need to decide when to do something quick and dirty versus laying more groundwork and infrastructure to support future features. Stakeholders need to have an idea where a product is developing and what might be coming down the road.

There are quite a few types of roadmaps, there are technology roadmaps, feature roadmaps, release roadmaps, stop list roadmaps, marketing, strategy and many others. This articles generally applies to any of these.

Waste Not, Want Not

One of the key tenants of Agile Development is to reduce and if possible eliminate waste. Waste is any extra work that is being performed by team mates that doesn’t directly add value during the agile sprints. One main source of waste is doing too much and too detailed estimating. If you want a team to commit to estimates then they have to spend a lot of time working through those estimates so that they have the necessary precision. However when you do this, this work is often just waste, since then the work isn’t done due to changing priorities or another team does the work and insists on repeating the process or the project is postponed and when its resumed things have changed.

Roadmaps tend to generate a lot of wasted work. Once a company wants a roadmap that everyone is committed to, then far too much time will have been spent working on the estimates. The trick here is to be willing to accept inaccurate estimates. Many studies have shown that inaccurate WAG (Wild-Ass Guesses) type estimates aren’t really any less accurate than carefully constructed ones. All you need to know for building a roadmap is the order of magnitude of an item, not the details.

Detailed estimates are only done when the stories are going to be performed by the agile team. This work usually happens as a part of backlog grooming in the sprint before the work is actually going to be done. This then ensures that the stories are properly broken down and that the work can fit into one sprint.

Accept the Roadmap as a Guideline

The best way to think of a roadmap is as a guideline for current thinking. It is a mechanism to elicit feedback which can then be used to produce a better roadmap. Publishing a roadmap as a “fait accompli” doesn’t serve nearly as well as using a roadmap as a starting point for a conversation.

Often getting customer feedback on direction without providing any context or ideas is quite difficult because customers don’t spend their time thinking about how you need to develop your product. With a roadmap they can see how your product will fit in (or not) with their future business directions. Then they can provide useful feedback on what will be useful, what will be irrelevant and what will actually be harmful.

Keep in mind that conversations are two way things and the only way to be successful is to incorporate the feedback received and to show that the time spent by the customer talking to you is worthwhile. Corporations that can incorporate and synthesize the feedback from hundreds of customers in an effective manner tend to be the companies that really shine.

Accept that Agile Works

A lot of times the push for a fixed roadmap is a result of the organization outside of R&D not being comfortable with the Agile idea of working on the most important story all the time. They liked the old days where a giant requirements document was produced and upper level management reviewed this and then felt comfortable that they could let R&D go off for a year or two to work on this without paying any more attention.

Generally it’s proven out that Agile is much more efficient and produces better products that meet customers’ needs much better than the old waterfall execute the requirements approach. But if upper management wants to know what R&D is doing they have to pay attention since things are fluid and always changing. This can be hard to accept, but now its being found that Agile can be applied to other parts of the organization and rather than older parts of the company dragging down the Agile parts, now all departments are going to Agile and its working very well for modern companies. In fact many people now believe that if a company doesn’t make this transition then it will become less and less competitive. The sad part is that Agile produces far better artifacts showing the progress of a project, you just need to learn how to use the tracking software to see them (another wastage is producing specialized reports just for upper management consumption).

Customer Connectedness

In the end, the goal is to be as customer connected as possible. Always working on the item in the product backlog with the highest value for the customer. This is now a proven principle for success. Dictating to customers what is good for them will just alienate your customers and send them elsewhere.

Creating a general roadmap that is used to get customer feedback and buy-in is just one tool of many to being a better customer connected company. And again the key secret ingredient is always adapting to change and not becoming fixed in your direction.

Of course when talking to customers and often other stakeholders, they will start out with how they need everything yesterday. But you have to steer the conversation to choosing priorities and not being brow-beaten into accepting that any estimates need to be shorter.

Summary

Roadmaps are great tools for having a conversation with stakeholders on the direction of a product. You just have to be careful not to fall into the trap that the roadmap is somehow a commitment that can never change. If done properly it can serve quite a few goals that are fully compatible with an Agile methodology.

If you are presenting a roadmap at a conference or WebEx, always prefix the presentation with that this is our current thinking and that we are always looking for feedback and ways to make the roadmap better.

At Sage Summit 2015 we introduced our new Web UIs for Sage 300. I’ve blogged a bit on the various user facing parts and a bit on the technologies used, but I haven’t had a chance yet to get into the internals of how they work. We’ve released the Web UIs for the Financial Modules and will be releasing the Operations Modules early in 2016. With these we will be releasing our SDK as well. Over time I’ll blog quite a bit about the details of all the components, but first we need to layout the major building blocks. Below is the architecture diagram I’ve shared before which is the architecture for the main Web UIs and a block for RESTful Web APIs, but there are some other components that need mentioning as well.

I’m going to start at the bottom of this diagram and work up. However there are some other components that aren’t mentioned here that we will bring in.

Within our framework we provide a lot base classes that you can inherit from, so generally the only code you need to provide is where something is different than the standard protocols or behaviors. When looking for framework components to help you, besides looking for services to call, look for classes that do 90% of what you need that you can extend (inherit from). ASP.Net MVC also makes extensive use of “convention over configuration”, so for a lot of things if you follow the standards then it saves you a lot of work and makes a number of things just work magically. Similarly we do the same things, so we can find and use your components as long as you follow the standards as outlined.

Business Logic

The Sage 300 Views are still the same. We didn’t even update the C View template for supporting this new framework. All the regular Sage 300 Business Logic (Views) is accessed through our .Net API.

Business Repositories

The Business Repositories convert our View API into something more like an ASP.Net MVC API. The Business Repositories are similar to the definitions that we generate from ViewDoc for different systems to make accessing all the various View fields more natural in the given framework. They provide support for all the usual View UI related items like presentation lists and field masks. Generally this is where all the View programming is placed that is needed by the UI. This makes all this programming available to everyone including UIs, standard components and Web APIs.

Models

The models are true ASP.Net MVC Models. They are typically built on a given business repository. The reason for the separation between the Business Repositories and the Models is that the Business Repositories are more general use and can easily be consumed by UI elements whose Models are more generic like for Finders or Import/Export.

State-full Versus Stateless

There are two basic ways that our UIs operate, stateless and state-full. Ideally everything should be stateless, but this becomes somewhat impractical when dealing with large accounting documents. Basically in stateless operation, each RPC operation is completely independent and can be processed with no knowledge of what’s gone before. For state-full transaction a document is built up in the Sage 300 Business Logic as the user enters the document, this is more similar to how the VB UIs work. Generally only the bigger document entry UIs are state-full now. Use of the two is similar and most of the details are hidden by which base class you inherit from (whether a state-full or stateless one), but you must beware of the context as you do your programming.

Controllers

The controllers mediate the translate the RPC calls from the JavaScript components running in the Browser to making calls the Models, Services and other API calls. Sounds like a lot of work, but typically these classes are quite compact.

Services

Often in VB programming, you handle events from the user and as a result of a UI event you do a certain amount of View calls (perhaps say 20 of these). This sort of thing also happens in the Web UI, but we certainly can’t do 20 or so RPC calls to the server as a result of a single UI interaction. This is where services come in. Then when such a UI event is triggered, a single RPC call is made to the server, the controller dispatches this to the service who calls the correct method in the Business Repository which then makes the 20 or so View calls to do the real work. The service then marshals any returned data in the response. Of course this all happens asynchronously. Generally if you are wondering where to move your processing code from a VB UI it would be into one of the Business Repositories and then wire up a service to allow it to be called from the Browser. Services are also used to initiate long running processes which we’ll talk about later.

Views

We use ASP.Net MVC Razor Views for our View components. This is a templating technology that allows us to dynamically generate the HTML using C# (which is embedded in the original HTML). For instance we allow translations to many languages, so rather than having embedded text strings, and then needing a separate copy of the HTML for each supported language, we have embedded C# functions that look up the correct language string which are processed and evaluated when we go to render the HTML. This is very handy and powerful in generating the HTML for each screen based on the various user and application contexts. There is also quite a bit of JavaScript associated with each screen to handle the various dynamic parts of the UI. Much of this is just a matter of wiring up the components like the screen UI elements to data binding or standard UI controls like the Kendo ones to our system JavaScript framework.

Sage.CNA.Windows.Service

We don’t want to run long running processes like I/C Day End or Posting Batches directly from IIS, since even with full multi-threading support this can adversely affect the responsiveness of the UIs for other users. So we run a Windows Service and when a long running process is initiated we ask the Windows Service to run it, and just return from IIS. Then the UI can inquire periodically for meter status updates and to notify the user when it’s done. There is a lot of standard framework support for doing this and you just need to setup a service to initiate and monitor the process. Generally we do this for any Sage 300 process that pops up a progress meter.

KPIs are really just like any other UI. They just have a different size and are run in a different place on the Home Page. There are a few standards to follow to match the other KPIs and a few UI controls that aren’t used anywhere else, but are otherwise just standard UIs.

Although this component isn’t included in the original Sage 300 2016 release, there is full support for exposing RESTful Web Service APIs. These leverage your Model code to expose the model as an API. Then there is some support for hiding inappropriate methods and adding a bit more attribute information to help users.

Printing

Like previous versions of Sage 300, we use Crystal Reports to print out our reports. We basically use the same report API as we used in VB. We then have support to call this API from our UI framework and to render the report in the Crystal HTML Viewer. Then the rest of the report UI is just the same as any other UI, gathering up data from input fields. Printing might also have to initiate a process on the Windows service before printing, like generating the data for an aging report, before initiating the report.

Other System Components

There are system components for things like Finders and Import Export. These just need to be setup and wired in correctly. Then there are components like the editable grid which requires a certain amount more support in your UI. And then higher level components like the Optional Fields Control that is built on the Grid. There are a few other controls and wrappers for things like dates, fiscal year/periods, masked edit control, drop down list based on presentation strings, etc.

Summary

This article is the start of drilling down into the internals of how our new Web UIs work. Hopefully it gives a flavor of the components that combine to make a Web UI. The UIs are fully Ajax Web Applications, so there is work to do both in the Browser in HTML, CSS and JavaScript as well on the server in C#. There are quite a few frameworks involved from Sage, Microsoft, Telerik and a number of open source libraries. The trick is to not be overwhelmed, but to start with a simple empty screen and one by one learn and add the elements that you need. The good thing is that the base classes you extend (inherit from) provide much of the standard code and often you don’t need to add very much at all.

We are just rolling out Sage 300 2016 which includes Web versions of Common Services, Bank Services, Tax Services, General Ledger, Accounts Receivables and Accounts Payables. The focus of this release isn’t on a new flashy portal with flashy KPIs (although we do have those) or other new technology enabled functionality. The focus is on the core Financial Accounting functionality; on entering financial accounting documents into the system and providing the key reports that go along with these.

This is the first of a series of releases that will translate the Sage 300 product line to a new Web based technology platform. It will move all the functionality of Sage 300 to this platform and use this new platform to add newer technologies and functionality.

This article is meant to give a quick overview and flavor for what you will see in our new Web UIs.

Common Services

A lot of Common Services are screens that enable functionality through the rest of the product. For instance the Optional Fields setup UI is present and is used to configure Optional Fields that then appear in so many other places. There are the usual basic common setup UIs for Company Profile and Calendar Services.

Bank Services is a part of Common Services and it provides a centralized place to manage your bank accounts. Reconcile bank statements and enter various bank related items like service charges. It also provides a common check printing UI for other applications to use when printing checks.

Tax Services is another part of Common Services that lets you configure your sales taxes in a single place and then they are used everywhere that involves sales taxes. You will see the full tax services support though out many Web UIs.

Sage Payment Solutions (SPS) is also configured from Common Services. We fully support Sage Payment Services for taking credit cards in A/R as part of this first release. We integrate to the Web versions of the SPS screens to take and process credit cards. As before no credit card information is stored in the Sage 300 database, its all handled by the SPS screens and saved in the SPS vault.

Although they aren’t supported by their own screens there is a lot of common functionality that goes across all the modules like Import/Export, Finders and processing custom Crystal reports. These are all present in the new Web UIs as well.

All these screens fully support multi-currency and fully honor Sage 300 security.

General Ledger

This module offers all the standard G/L screens. From here you can define your G/L Account structure, create and maintain your G/L Accounts and enter your G/L Journal Entries. Generally everything is G/L is based on fiscal year and period (which we provide a specialized control to enter) and allows you to follow GAAP rules exactly.

Accounts Receivable

Here you have all the screens to setup and maintain you’re A/R sub-ledger. You have screens to enter and maintain Customers. There are the main document entry screens of Invoice Entry and Receipt Entry. There is integration to SPS for credit card transactions. There is retainage accounting, optional fields, sales tax calculations and all the rich functionality you are used to.

Accounts Payable

Here you have all the screens to setup and maintain you’re A/P sub-ledger. You have screens to enter and maintain Vendors. There are the main document entry screens of Invoice Entry and Payment Entry. You can track vendor account and transaction details on screen and on printed reports. Accounts Payable produces the reports you need to avoid late payment charges, secure vendor discounts, and match cash requirements to cash resources. There is tight integration to Bank for printing and tracking checks.

Summary

Hopefully you will try out our new Web technology for the Sage 300 UIs. This moves Sage 300 to a fully supported technology platform that continues to evolve quickly. This first release offers lots of functionality across all of Financial Accounting with new releases coming quickly to provide the rest.

If you remember our last UI transition from CA-Realizer to VB6, you will see that this one is happening at a much quicker pace.

Since the Business Logic is still the same as the existing product, you know that this is a very full featured and robust set of accounting functionality that has been in use at a great many companies for quite a few years now.

Sage 300 2016 has now been “Released to Manufacturing”. This is a bit of an archaic term since we don’t manufacture anything anymore. It really means that R&D has handed the product over to the next step in the chain that will allow it to be installed at customer locations. This is a staged plan where it first goes to “controlled release” customers and then out to the wider audience in phases. The important thing is that the software is ready for customers to go live with in production environments.

Recently I’ve blogged quite a bit on the new Web UIs, but in this article we cover all areas of the product.

Web UIs

The marquee feature is of course the new Web UIs. You can now run Common Services, General Ledger, Accounts Payable and Accounts Receivable from Internet Explorer, Edge, Chrome, Safari or Firefox. There is a nice Home Page with KPIs, good international support and many usability enhancements. You can now easily access Sage 300 from a Mac, Linux computer or tablet.

Easier Installation

You no longer need to run Day End, post outstanding batches or complete bank reconciliation before upgrading. This should make it much easier to schedule when you perform the upgrade as you no longer need to sync with these other ongoing processes.

We now run regacc.exe during installation (full and workstation setup), so that you don’t need to do this as a separate step if you want your users to run with lower permissions (more on that later). This is also run during un-installation to clean up the registry.

Better UAC Support

The goal of this support is that regular users can run day to day without requiring power user or administrator rights and that they can leave User Account Control (UAC) turned on. This means that there won’t be any registering of controls as the user runs (this is all done at installation time) and we’ve moved where we store things in the registry so a regular user won’t be required to write to HKEY_LOCAL_MACHINE. Of course to install the software you still need to be Administrator and the usual procedures still apply.

Support Newer Microsoft Products

With this release we add support for Windows 10, Office 2016 and SQL Server 2016.

Note that we no longer support Pervasive.SQL or Oracle. Further we only support Windows 7 (SP1), Windows 8.1 and Windows 10. I.e. we do not support Windows Vista or Windows 8. We also only support the 64 bit versions of the operation systems, we no longer support the 32 bit versions.

Check the system requirements KB article for all the gory details.

Payroll 7.2

This release includes Payroll 7.2 (which is also available for Sage 300 2012 and 2014). For US Payroll this includes cost center overrides and ACA reporting. For Canadian Payroll it includes the PIER balancing report and the T4A/R2 Report.

Miscellaneous

The G/L Transaction Listing Report can now be run either by document date or by posting date.

G/L Journal Entry has an “Entered by” field.

A post button was added to the main document entry screens like G/L Journal Entry so you don’t need to go to the batch list to post the batch.

The tax tracking report can now be from/to a fiscal year/period.

The Tax Clear History function has been moved out of the Tax Tracking report and into a separate periodic processing function.

Integrations

With every release we update the various integrations that are included with the product. Make sure you also update these integrations like Sage CRM 7.3 to get all the benefits from that update as well.

Summary

Lots of new things in Sage 300 2016. Especially check out the new Web UIs. Besides the features mentioned there are always lots of bug fixes and minor improvement under the covers that improve the stability and performance of the product.